Tim Peters | 1 Apr 2000 02:55
Picon

A surprising case of cyclic trash

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()
(Continue reading)

Christian Tismer | 1 Apr 2000 16:55

Re: Re: [Python-checkins] CVS: python/dist/src/Misc ACKS,1.51,1.52


Moshe Zadka wrote:
> 
> On Fri, 31 Mar 2000, Guido van Rossum wrote:
> 
> > + Christian Tismer
> > + Christian Tismer
> 
> Ummmmm....I smell something fishy here. Are there two Christian Tismers?

Yes! From time to time I'm re-doing my cloning experiments.

This isn't so hard as it seems. The hard thing is to keep
them from killing each other. BTW: I'm the second copy
from the last experiment (the surviver).

> 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.

Guido is stronger, even between three of me :-)

ciao - chris-and-the-undead-heresy

--

-- 
Christian Tismer             :^)   <mailto:tismer <at> appliedbiometrics.com>
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
(Continue reading)

Guido van Rossum | 1 Apr 2000 19:00
Favicon

New Features in Python 1.6

New Features in Python 1.6
==========================

With the recent release of Python 1.6 alpha 1, a lot of people have
been wondering what's new.  This short note aims to explain the major
changes in Python 1.6.

Core Language
-------------

1. Unicode strings

Python strings can now be stored as Unicode strings.  To make it easier
to type Unicode strings, the single-quote character defaults to creating
a Unicode string, while the double-quote character defaults to ASCII
strings.  If you need to create a Unicode string with double quotes,
just preface it with the letter "u"; likewise, an ASCII string can be
created by prefacing single quotes with the letter "a".  For example:

   foo = 'hello'                # Unicode
   foo = "hello"                # ASCII
   foo = a'hello'               # ASCII
   foo = u"hello"               # Unicode

You can still use the "r" character to quote strings in a manner
convenient for the regular expression engine, but with subtle changes in
semantics: see "New regular expression engine" below for more
information.

Also, for compatibility with most editors and operating systems, 
(Continue reading)

gvwilson | 1 Apr 2000 20:01

Re: New Features in Python 1.6

> 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")

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

p.s. "There's More Than One Way To Do It" == "No Matter How Much Of This
Language You Learn, Other People's Code Will Always Look Strange"

gvwilson | 1 Apr 2000 20:45

RE: New Features in Python 1.6

> >> 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 "&lt;" to be a legal
Python token :-).

Greg

est | 2 Apr 2000 00:00

linuxaudiodev minimal test

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()
(Continue reading)

Vladimir Marangozov | 2 Apr 2000 01:30
Picon

python -t gets confused?

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 <at> inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Mark Hammond | 2 Apr 2000 01:53
Picon
Favicon
Gravatar

string.ato? and Unicode

Is this an over-sight, or by design?

>>> string.atoi(u"1")
...
TypeError: argument 1: expected string, unicode found

It appears easy to support Unicode - there is already an explicit
StringType check in these functions, and it simply delegates to
int(), which already _does_ work for Unicode

A patch would leave the following behaviour:
>>> string.atio(u"1")
1
>>> string.atio(u"1", 16)
...
TypeError: can't convert non-string with explicit base

IMO, this is better than what we have now.  I'll put together a
patch if one is wanted...

Mark.

Tim Peters | 2 Apr 2000 06:14
Picon

RE: python -t gets confused?

[Vladimir Marangozov]
> 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 :)

They're not confused, they're simply reporting that the indentation is
screwed up in this file -- which it is.  It mixes tabs and spaces in
ambiguous ways.

> ...
> 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.

If you set your editor to believe that tab chars are 4 columns (as my
Windows editor does), the problem (well, problems -- many lines are flawed)
will be obvious.  It runs anyway because tab=8 is hardcoded in the Python
parser.

Quickest fix is for someone at CNRI to just run this thru one of the Unix
detabifier programs.

Tim Peters | 2 Apr 2000 08:18
Picon

RE: Windows installer pre-prelease

> The Windows installer is always hard to get just right. ...
> ...
> I'd love to hear that it also installs cleanly on Windows 95.  Please
> test IDLE from the start menu!

All worked without incident for me under Win95.  Nice!  Would still prefer
that it install to D:\Python-1.6\ by default, though (instead of burying it
under "Program Files" -- if you're not on the Help list, you can't believe
how hard it is to explain how to deal with embedded spaces in paths).

So far I've seen one system crash in TK83.DLL upon closing an IDLE window,
but haven't been able to reproduce.  OK, I can, it's easy:

Open IDLE.
Ctrl+O, then navigate to e.g. Tools\idle\config.txt and open it.
Click the "close window" button.

Boom -- invalid page fault in TK83.DLL.  No time to dig further now.


Gmane