Mailman 3 April 2000 - Python-Dev

python -t gets confused?
by Vladimir.Marangozov＠inrialpes.fr April 2, 2000

April 2, 2000

The tab/space checking code in the tokenizer seems to get confused by the recently checked in test_pyexpat.py With python -t or -tt, there are inconsistency reports at places where there doesn't seem to be one. (tabnanny seems to be confused too, btw :) ./python -tt Lib/test/test_pyexpat.py File "Lib/test/test_pyexpat.py", line 13 print 'Start element:\n\t', name, attrs ^ SyntaxError: inconsistent use of tabs and spaces in indentation Thus, "make test" reports a failure on test_pyexpat due to a syntax error, instead of a missing optional feature (expat not compiled in). I'm not an expert of the tokenizer code, so someone might want to look at it and tell us what's going on. Without -t or -tt, the code runs fine. -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

2 1

linuxaudiodev minimal test
by est＠hyperreal.org April 1, 2000

April 1, 2000

The appended script works for me. I think the module should be called something like OSS (since it uses the Open Sound System API) with a -I entry in Setup.in to indicate that this will probably need to be specified to find <soundcard.h> (e.g., -I/usr/include/linux for Linux, -I/usr/include/machine for FreeBSD...). I'm sure I'll have other suggestions for the module, but they'll have to wait until I finish moving to California. :) Best, Eric #!/usr/bin/python import linuxaudiodev import math, struct, fcntl, FCNTL a = linuxaudiodev.open('w') a.setparameters(44100, 16, 1, linuxaudiodev.AFMT_S16_LE) N = 500 data = apply(struct.pack, ['<%dh' % N] + map(lambda n: 32767 * math.sin((2 * math.pi * n) / N), range(N))) fd = a.fileno() fcntl.fcntl(fd, FCNTL.F_SETFL, ~FCNTL.O_NONBLOCK & fcntl.fcntl(fd, FCNTL.F_GETFL)) for i in xrange(200): a.write(data)

1 0

RE: [Python-Dev] New Features in Python 1.6
by gvwilson＠nevex.com April 1, 2000

April 1, 2000

> >> On Sat, 1 Apr 2000, Guido van Rossum wrote: > >> New Features in Python 1.6 > >> ========================== > >> [lots 'n' lots] > >> tokens = "foo bar baz".split(" ") > >> tokens = " ".split("foo bar baz") > >> [and Python guesses which to split on by studying the contents] > > > Has anyone started working up a style guide that'll recommend when > > to use these new methods, when to use the string module's calls, > > etc.? Ditto for the other changes --- where there are now two or > > more ways of doing something, how do I (or my students) tell which > > one is preferred? > > Greg, you should pay real close attention to the date on Guido's msg. > It's quite a comment on the state of programming languages in general > that this all reads sooooooo plausibly! Well, you have to remember, I'm the guy who asked for "<" to be a legal Python token :-). Greg

1 0

Re: [Python-checkins] CVS: python/dist/src/Misc ACKS,1.51,1.52
by Moshe Zadka April 1, 2000

April 1, 2000

On Fri, 31 Mar 2000, Guido van Rossum wrote: > + Christian Tismer > + Christian Tismer Ummmmm....I smell something fishy here. Are there two Christian Tismers? That would explain how Christian has so much time to work on Stackless. Well, between the both of them, Guido will have no chance but to put Stackless in the standard distribution. -- Moshe Zadka <mzadka(a)geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com

2 1

A surprising case of cyclic trash
by Tim Peters April 1, 2000

April 1, 2000

This comes (indirectly) from a user of my doctest.py, who noticed that sometimes tempfiles created by his docstring tests got cleaned up (via __del__), but other times not. Here's a hard-won self-contained program illustrating the true cause: class Critical: count = 0 def __init__(self): Critical.count = Critical.count + 1 self.id = Critical.count print "acquiring Critical", self.id def __del__(self): print "releasing Critical", self.id good = "temp = Critical()\n" bad = "def f(): pass\n" + good basedict = {"Critical": Critical} for test in good, bad, good: print "\nStarting test case:" print test exec compile(test, "<string>", "exec") in basedict.copy() And here's output: D:\Python>python misc\doccyc.py Starting test case: temp = Critical() acquiring Critical 1 releasing Critical 1 Starting test case: def f(): pass temp = Critical() acquiring Critical 2 Starting test case: temp = Critical() acquiring Critical 3 releasing Critical 3 D:\Python> That is, in the "bad" case, which differs from the "good" case merely in defining an unreferenced function, temp.__del__ not only doesn't get executed "when expected", it never gets executed at all. This appears to be due to a cycle between the function object and the anonymous dict passed to exec, causing the entire dict to become immortal, thus making "temp" immortal too. I can fiddle the doctest framework to manually nuke the temp dict it creates for execution context; the same kind of leak likely occurs in any exec'ed string that contains a function defn. For future reference, note that the finalizer in question belongs to an object not itself in a cycle, it's an object reachable only from a dead cycle. the-users-don't-stand-a-chance<wink>-ly y'rs - tim

1 0