Edited by author 01-19-2005 04:24 PM
Stewart, running the tkFileDialog and tkFont modules as scripts gives the same error on my machine (not that it's an error inside Tkinter itself) only when I've messed up the paths. I tried running the 2.4 modules using a 2.3 interpreter; doesn't work. With the right versions, everything works just fine.

Edited by author 01-20-2005 03:13 AM
As far as I can tell, ElementTree is a bit slower with psyco than it is without it. It's simply too much C code involved (pyexpat), and too many calls from C code to Python.

(note that pure-Python parsers are typically 1000-10000 times slower than cElementTree. it's a lot more than just a straightforward translation to C...)

good suggestion to file a bug - someone else had recently noticed the same problem, filed a bug, and a solution. I may be able to patch my own copy of tkFileDialog, or get the tip versio off the CVS tree.
The bug is here:
https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=852314
thanks
S



On 19 Jan 2005 21:16:57 -0000, QT - Fredrik Lundh
<qtopic+28-v2dA7ee7u55Jx@quicktopic.com> wrote:

> Stewart, running the tkFileDialog and tkFont modules as scripts
> gives the same error on my machine (not that it's an error
> inside Tkinter itself), but both modules seem to work just fine
> if you call the functions from inside a program. Please report
> it to the Python developers:
> http://sourceforge.net/bugs/?group_id=5470

--
Stewart Midwinter
stewart@midwinter.ca
stewart.midwinter@gmail.com

That SF bug might explain the la-la-land, but it doesn't explain why the exceptions you got under 2.4 were identical to the exceptions I got when I tried to use 2.4's Tkinter with a 2.3 interpreter. Methinks you reported two bugs, one of which was a pilot error.

<smack!> (sound of palm slapping forehead). Now the light goes on. I tested the tkFileDialog from 2.4 by opening it in the SciTE editor, then executing it from there. By default, SciTE just calls "python", and the default python installation for me is 2.3, even if I have 2.4 (and 1.52) installed as well.

I'll go back and run it from a command prompt and see what happens. I'm sure it will work properly then.

Thanks!
S

Hey, don't you think it would be a good idea to have cElementTree in python standard library?? I find it way more useful than current standard xml lib.. besides it would contribute in making python faster at least in XML processing.

Just want to thank you for your great work, I use this little thing almost everywhere.

Edited by author 01-21-2005 09:28 AM
By Default, SciTE doesn't "just call 'python'", though it looks like it does. Check your python.properties (Options -> Open python.properties) at the very bottom of that file are two lines that have "C:\python23\python.exe" and "C:\python23\pythonw.exe", you can modify to your hearts content. (If you don't have Open python.properties as an option, you're running the single-executable version, the easy solution is to grab the full version)

thanks Timothy for that tip. I am aware of the Python Properties file, and frequently use it to alternate between different Python versions on my PC. In this case, though, I had updated to 2.4 and forgot to also update that Properties file.

S

Edited by author 01-22-2005 09:49 AM
cElementTree in the standard library? why not; it wouldn't be the first thing I've written that makes it into the library... but I'm not going to lobby for that myself; I usually leave such things to enthusiastic users (that was a hint ;-)

I love the new iterparse function, but one thing about the example you give bothers me. The SAX documentation warns that the order in which namespaces start and end may not be nested "properly" with respect to each other. I see that the 'end-ns' event from iterparse just returns None, are we to conclude that this means namespace declarations which come into and go out of scope on the same element will be nested appropriately?

Edited by author 01-24-2005 12:34 PM
"are we to conclude that this means namespace declarations which come into and go out of scope on the same element will be nested appropriately"

That's the intention, at least. I guess I have to add some more tests to make sure that this is always true...

Just another note to the pystone numbers: When I read the Uche's article this morning, I computed the pystone for my desktop machine, and although the CPU is less powerful (1.4 GHz Athlon), the came out higher. On my ThinkPad T41p, which has 512MiB of RAM and a 1.7GHz Pentium-M and therefore comparable to his Dell notebook, I get the following numbers:
Pystone(1.1) time for 50000 passes = 1.33
This machine benchmarks at 37594 pystones/second

Python is 2.3.4. Either my notebook is magically enhanced (which it of course is), Debian is outrageously faster than FC3 (true, too) or something is wrong about his numbers.
Anyway, keep up the good work, I look forward to adding (c)ElementTree packages to Debian soon and using it in my own software!

The article says: "It's a Centrino 1.7GHz, which is about equivalent to a P4-3GHz"

Unfortunately, this is unlikely to be true, and you can see that from the Pystone results. It may be the case that Centrino bundles use Pentium-M CPUs, but for all I know (and care) it could be a Celeron on the motherboard. Anyway, apart from all the power-saving horseplay that could go on, the main difference between Pentium-M and P4 is probably the cache - again, from my own limited knowledge of the field and my P2-266-based perspective of the world.

http://www.intel.com/products/notebook/pro...celeron_m/index.htm
says that Celeron M processors go only up to 1.5 GHz, and 8600s are delivered with Celeron M or Pentium M.

I seem to have too much time at my hands to actually care about that;-). On the other hand, google is just too handy...

Edited by author 01-26-2005 03:35 PM
I think there's a problem with your latest benchmark: it looks like you're only measuring the time it takes to create the generator object. It doesn't look like your code is executing. If you wrap the generator in a list(), to force execution, the timing takes longer. (I'm using the tiny samples/simple.xml from the cElementTree zip, below.)

(dn@change)(02:22P)
(%:~/src/cElementTree-1.0-20050126)- python2.4 -m timeit -s "import cElementTree" "matches = (elem.get('value') for event, elem in cElementTree.iterparse('samples/simple.xml') if elem.get('name') == 'reselectApi')"
10000 loops, best of 3: 23.9 usec per loop

(dn@change)(02:23P)
(%:~/src/cElementTree-1.0-20050126)- python2.4 -m timeit -s "import cElementTree" "matches = list(elem.get('value') for event, elem in cElementTree.iterparse('samples/simple.xml') if elem.get('name') == 'reselectApi')"
10000 loops, best of 3: 116 usec per loop

[Had to edit my post -- had pasted the same timing twice, now fixed.]