Mailman 3 August 2000 - Python-Dev

Lukewarm about range literals
by Guido van Rossum Aug. 31, 2000

Aug. 31, 2000

I chatted with some PythonLabs folks this morning and nobody had any real enthusiasm for range literals. I notice that: for i in [:100]: print i looks a bit too much like line noise. I remember that Randy Pausch once mentioned that a typical newbie will read this as: for i in 100 print i and they will have a heck of a time to reconstruct the punctuation, with all sorts of errors lurking, e.g.: for i in [100]: print i for i in [100:]: print i for i in :[100]: print i Is there anyone who wants to champion this? Sorry, Thomas! I'm not doing this to waste your time! It honestly only occurred to me this morning, after Tim mentioned he was at most lukewarm about it... --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

16 48

Re: [Python-checkins] CVS: python/dist/src/Modules Makefile.pre.in,1.63,1.64
by bwarsaw＠beopen.com Aug. 31, 2000

Aug. 31, 2000

>>>>> "Fred" == Fred L Drake <fdrake(a)users.sourceforge.net> writes: Fred> If Setup is older than Setup.in, issue a bold warning that Fred> the Setup may need to be checked to make sure all the latest Fred> information is present. Fred> This closes SourceForge patch #101275. Not quite. When I run make in the top-level directory, I see this message: ------------------------------------------- ./Setup.in is newer than Setup; check to make sure you have all the updates you need in your Setup file. ------------------------------------------- I have to hunt around in my compile output to notice that, oh, make cd'd into Modules so it must be talking about /that/ Setup file. "Then why did it say ./Setup.in"? :) The warning should say Modules/Setup.in is newer than Modules/Setup. -Barry

1 0

[Fwd: [Python-Dev] test_gettext.py fails on 64-bit architectures]
by Mark Favas Aug. 31, 2000

Aug. 31, 2000

-- Email - m.favas(a)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

1 0

Silly correction to: [Python-Dev] linuxaudiodev test does nothing
by Charles G Waldman Aug. 31, 2000

Aug. 31, 2000

I wrote: > x.setparameters(8000, 1, 8, linuxaudiodev.AFMT_MU_LAW ) where I meant: > x.setparameters(8000, 8, 1, linuxaudiodev.AFMT_MU_LAW ) In fact I tried just about every combination of arguments, closing and reopening the device each time, but still no go. I also wrote: > Maybe I'll clean it up and submit it for inclusion post-1.6 where of course I meant to say post-2.0b1

1 0

Re: [Python-Dev] stack check on Unix: any suggestions?
by Jack Jansen Aug. 31, 2000

Aug. 31, 2000

I'm confused now: how is this counting-stack-limit different from the maximum recursion depth we already have? The whole point of PyOS_StackCheck is to do an _actual_ check of whether there's space left for the stack so we can hopefully have an orderly cleanup before we hit the hard limit. If computing it is too difficult because getrlimit isn't available or doesn't do what we want we should probe it, as the windows code does or my example code posted yesterday does. Note that the testing only has to be done every *first* time the stack goes past a certain boundary: the probing can remember the deepest currently known valid stack location, and everything that is shallower is okay from that point on (making PyOS_StackCheck a subroutine call and a compare in the normal case). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)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

4 3

test_gettext.py fails on 64-bit architectures
by Mark Favas Aug. 31, 2000

Aug. 31, 2000

(Tru64 Unix) - test_gettext fails with the message: IOError: [Errno 0] Bad magic number: './xx/LC_MESSAGES/gettext.mo' This is because the magic number is read in by the code in Lib/gettext.py as FFFFFFFF950412DE (hex) (using unpack('<i', buf[:4])[0]), and checked against LE_MAGIC (defined as 950412DE) and BE_MAGIC (calculated as FFFFFFFFDE120495 using struct.unpack('>i',struct.pack('<i', LE_MAGIC))[0]) These format strings work for machines where a Python integer is the same size as a C int, but not for machines where a Python integer is larger than a C int. The problem arises because the LE_MAGIC number is negative if a 32-bit int, but positive if Python integers are 64-bit. Replacing the "i" in the code that generates BE_MAGIC and reads in "magic" by "I" makes the test work for me, but there's other uses of "i" and "ii" when the rest of the .mo file is processed that I'm unsure about with different inputs. Mark -- Email - m.favas(a)per.dem.csiro.au Postal - Mark C Favas Phone - +61 8 9333 6268, 041 892 6074 CSIRO Exploration & Mining Fax - +61 8 9333 6121 Private Bag No 5 Wembley, Western Australia 6913

2 1

Re: [Python-checkins] CVS: python/dist/src/Objects abstract.c,2.49,2.50
by Fred L. Drake, Jr. Aug. 31, 2000

Aug. 31, 2000

Thomas Wouters writes: > Fix grouping: this is how I intended it, misguided as I was in boolean > operator associativity. And to think I spent time digging out my reference material to make sure I didn't change anything! This is why compilers have warnings like that! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

3 4

Threads & autoconf
by Mark Favas Aug. 31, 2000

Aug. 31, 2000

[Thomas} >I'm trying to clean up the autoconf (and README) mess wrt. threads a bit, >but I think I need some hints ;) I can't figure out why there is a separate >--with-dec-threads option... Is there a reason it can't be autodetected like >we do for other thread systems ? Does DEC Unix do something very different >but functional when leaving out the '-threads' option (which is the only >thing -dec- adds) or is it just "hysterical raisins" ? Yes, DEC Unix does do something very different without the "-threads" option to the "cc" line that finally builds the python executable - the following are unresolved: cc python.o \ ../libpython2.0.a -L/usr/local/lib -ltk8.0 -ltcl8.0 -lX11 -ldb -L/usr/local/lib -lz -lnet -lpthreads -lm -o python ld: Unresolved: _PyGC_Insert _PyGC_Remove __pthread_mutex_init __pthread_mutex_destroy __pthread_mutex_lock __pthread_mutex_unlock __pthread_cond_init __pthread_cond_destroy __pthread_cond_signal __pthread_cond_wait __pthread_create __pthread_detach make[1]: *** [link] Error 1 So, it is still needed. It should be possible, though, to detect that the system is OSF1 during configure and set this without having to do "--with-dec-threads". I think DEEC/Compaq/Tru 64 Unix is the only current Unix that reports itself as OSF1. If there are other legacy systems that do, and don't need "-threads", they could do "configure --without-dec-threads" <grin>. Mark -- Email - m.favas(a)per.dem.csiro.au Postal - Mark C Favas Phone - +61 8 9333 6268, 041 892 6074 CSIRO Exploration & Mining Fax - +61 8 9333 6121 Private Bag No 5 Wembley, Western Australia 6913

1 0

Release deadline looming (patches by Aug. 31)
by Jeremy Hylton Aug. 30, 2000

Aug. 30, 2000

[Apologies for the short notice here; this was lost in a BeOpen mail server for about 24 hours.] We are still on schedule to release 2.0b1 on Sept. 5 (Tuesday). There are a few outstanding items that we need to resolve. In order to leave time for the admistrivia necessary to produce a release, we will need to have a code freeze soon. Guido says that typically, all the patches should be in two days before the release. The two-day deadline may be earlier than expected, because Monday is a holiday in the US and at BeOpen. So two days before the release is midnight Thursday. That's right. All patches need to be completed by Aug. 31 at midnight. If this deadline is missed, the change won't make it into 2.0b1. If you've got bugs assigned to you with a priority higher than 5, please try to take a look at them before the deadline. Jeremy

1 0

Re: [Python-Dev] stack check on Unix: any suggestions?
by Martin v. Loewis Aug. 30, 2000

Aug. 30, 2000

> My SGI has getrlimit(RLIMIT_STACK) which should do the trick It tells you how much stack you've got; it does not tell you how much of that is actually in use. > Unix code will also have to differentiate between running on the > main stack and a sub-thread stack, probably. My patch computes (or, rather, estimates) a start-of-stack for each thread, and then saves that in the thread context. > And I haven't looked at the way PyOS_CheckStack is implemented on > Windows It should work for multiple threads just fine. It tries to allocate 8k on the current stack, and then catches the error if any. Regards, Martin

1 0