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
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)
> >> 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
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.htmlhttp://www.linux.org.il -- we put the penguin in .com
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
