ANN: pyvm 2.0
Hi. After a long period, the next version of pyvm is finally out! pyvm is a small hobby project that's based on a vm that is a cousin of Python and attempts to reimplement a full userspace system with the use of a monolithic toolchain with internal APIs. The result is a very compact codebase which partly implements many userspace applications. However, the project is not suitable for simple users. It is an on-going half-finished project that might interest other programmers. Currently the source code works only in x86/linux (32bit). The homepage is http://students.ceid.upatras.gr/~sxanth/pyvm-2.0/ -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: A defense for bracket-less code
Edward Elliott wrote:
Dave Hansen wrote:
Not really. It was mostly a lead-in to that last sentence. Problems
like this couldn't happen in Python. So it's an opportunity to get a
giggle at the expense of programmers using a language that gives you
enough rope to shoot yourself in the foot...
Which can be entirely avoided by making the braces mandatory rather than
optional. This is one thing perl got right:
while (foo);# parse error
while (foo) next; # parse error
while (foo) { next; } # ok
while (foo) { } # ok
And if you compile C++ without a lint checker, well, you're playing with
fire. :)
Since the whitespaceless frontend seems relevant here, may I add that:
bugs happen. Such statement bugs are very easy to detect once you
see that something's going wrong. If only all the bugs were as simple
as statement bugs! But unfortunatelly, less than 0.1% of the bugs I've
encountered so far are statement bugs :(
Also, I think that perl does that because otherwise code like
if ($x) $y++ if $z; else $z--;
would be even more confusing :)
Stelios
--
http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
Hi, [EMAIL PROTECTED] wrote: but maybe instead of the global.name something to refer to the upper namespace (that can be the global one or the namespace of the function that contains this one) can be more general: upper.x = 1 upper.upper.x = 1 Well, people have been trying to come up with a way to solve the nested scopes restrictions. This may work, but in my opinion nested functions are not so important and I wouldn't spend any time to improve them. Usually you can do anything with classes (and method makes that easier). If we say that closures were invented so that we will avoid the extra typing in cases like def f (self): x = lambda self=self: return self.foo () and beyond that perhaps it is a sign that we should rethink our design we can accept the limitations of python's closures. I think that making self a reserved word that can be used only for its usual purpose can be positive. I agree. EPL does not have shoot-self-in-the-foot protections yet, but it will :) The $ and method statement seem interesting too, but the first is a little perlish (but Ruby has something similar, and people like it), and the method statement look a little redundant. I think the $ can be acceptable (Mostly to reduce typing), even if it doesn't look very nice. '$' is perlish and rubyish (and I got it from ruby indeed). It's the cost of a dynamic language :) In static languages we know at compile-time whether a symbol is local, instance or global. In dynamic languages where scopes are modified when the program runs we have to type something. '$' being unused seems like a good choice. method is good not only because we avoid the extra typing in the definition, but also because -after experiments- it seems that restricting the use of $ in methods, will simplify some confusing cases. For example, what happens in: def foo (cls): def bar (self): return $x # what's that? cls.x or self.x? While now, when you see $ you know it refers to the instance of the method. And nested methods in methods are very rare. Bye, Stelios - sorry for the delayed reply. Unexpected easter vacation. -- http://mail.python.org/mailman/listinfo/python-list
The whitespaceless frontend
It had to happen :) http://pyvm32.infogami.com/EPL Seriously, this is not so much about the whitespace as for the new features, which might interest people who are thinking about new features. More specifically, methods and the $ operator are really great and seem to solve the problem with having to type self. all the time. The new syntax has been tested in core libraries of pyvm. Feedback is welcome, but preferably not in c.l.py because indentation can be a dangerous topic :) Cheers, Stelios -- http://mail.python.org/mailman/listinfo/python-list
pyvm 1.1
WHAT IS IT -- pyvm is an experimental python virtual machine with a compiler written in python. pyvm is very incomplete and does not care about backwards compatibility so you shouldn't use it unless: - you are interested in vm hacking. - you want to build another big program based on a fork of pyvm. - you have a lot of free time and you are very bored. WHERE IS IT --- http://students.ceid.upatras.gr/~sxanth/pyvm/ WHAT'S NEW -- In this release pyvm has real lightweight threads (co-routines). That is that there are two OS threads, one running the main interpreter loop and another one polling for file descriptors. When there is a blocking system call, the main interpreter thread passes a request to the polling thread and removes the co-routines from the running list. With this setup, pyvm can run unlimited python threads with just two OS threads. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
pyvm source code
Hi. pyvm is a program that can run python 2.4 bytecode. It can also run the bytecode of the 'pyc compiler' and consequently it can run python source code. It's written from the scratch and it has only been tested on a x86/Linux system. It's not portable yet, neither ready for the simple user, not to mention that gcc = 3.4 is required to compile it :) What's good about it is that it's small and easier to hack and write large scale programs using pyvm as the base runtime. On the other hand, pyvm is not compatible with python and AFAIC there is no plan doing this as a hobby. The source code is available under LGPL at: http://students.ceid.upatras.gr/~sxanth/pyvm/ Enjoy, Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Speed quirk: redundant line gives six-fold speedup
Mark Dickinson wrote: I have a simple 192-line Python script that begins with the line: dummy0 = 47 The script runs in less than 2.5 seconds. The variable dummy0 is never referenced again, directly or indirectly, by the rest of the script. Here's the surprise: if I remove or comment out this first line, the script takes more than 15 seconds to run. So it appears that adding a redundant line produces a spectacular six-fold increase in speed! (Actually, I had to add 29 dummy lines at the beginning of the code to get the speed increase; if any one of these lines is removed the running time reverts to around 15 seconds again.) Questions: (1) Can anyone else reproduce this behaviour, or is it just some quirk of my setup? (2) Any possible explanations? Is there some optimization that kicks in at a certain number of lines, or at a certain length of bytecode? (3) If (2), is there some way to force the optimization, so that I can get the speed increase without having to add the extra lines? Hi. I haven't been able to reproduce this but I had a similar case before (a program that some times crashed and some times worked perfectly and the difference was whitespace in the comments!!!). After lots of wondering and thinking that I must be dreaming (luckily I had pyvm which also crashed but for different amounts of whitespace), it was solved. The explanation is this: hash and comparison of objects depends on the state of the memory allocator. A sample case is this: class A: pass dummy0=47 # comment this to get a different result for min a=A() b=A() print min (a, b) the result of 'min' is not only non-deterministic but also depends on whether other things have been allocated before. The same thing can happen for 'dictionary.keys()' if the keys are objects and 'iterate-over-set' when the set contains objects. In the sudoku solver, there is a min (number, object) which is probably what's affected by the extistance of the dummy variable. Now, in sudoku puzzles some times the algorithm has to suppose that in a box the right solution is one of the possible, try it and if it fails then try the other one. I guess that the result of from the different 'min' leads the solver to first try the correct solution in the fast case and therefore need not attempt the wrong one. Or at least this is what I think that happens. By the way, since we started posting code, here is a more pythonic sudoku solver. #The 'man with scissors runs around shifting barrels algorithm' from sys import argv SEMANTIC = 1'SEM' in argv class Impossible: pass Patterns = [] for r in range (9): for c in range (9): p = 27*(r/3) + 3*(c/3) pl = set (range (9*r, 9*r+9) + range (c, 81, 9) + [p+x for x in (0,1,2,9,10,11,18,19,20)]) pl.remove (9*r+c) Patterns.append (tuple (sorted (list (pl def initboard (): x = range (1, 10) return [ x [:] for i in xrange (9*9) ] def printboard (board): if not SEMANTIC: return print 30*'-' for i in range (9): for j in board [9*i:9*(i+1)]: if type (j) is list: #print 'X', print ''.join (map (str, j)), else: print j, print print 30*'-' def dupboard (board): B = [] for i in board: if type (i) is list: B.append (i [:]) else: B.append (i) return B def solve (board, coords): while coords: p, v = coords.pop () board [p] = v for i in Patterns [p]: if type (board [i]) is list: if v in board [i]: board [i].remove (v) if len (board [i]) == 1: board [i] = board [i][0] coords.append ((i, board [i])) else: if board [i] == v: raise Impossible for p, i in enumerate (board): if type (i) is list: for j in i: try: return solve (dupboard (board), [(p, j)]) except Impossible: pass raise Impossible return board PP = [ [ 7xx19, 46x19, xxx6827x4, x9xx7, xxx3xx4x5, xx67x, xx1xx, 2xxx74xxx, xxx2xx3xx, ] ] def puz2coord (P): if len (P) != 9: print P must have 9 rows raise SystemExit coords = [] for r, i in enumerate (P): if len (i) != 9: print Row [%s] doesn't have 9 columns %i raise SystemExit for c, j in enumerate (list (i)): if j != 'x': coords.append ((9*r + c, int (j))) return coords try: if SEMANTIC: for i in xrange (10): for P in PP: printboard (solve (initboard (), puz2coord (P))) else: for i in xrange (TIMES): for P in PP: printboard (solve (initboard (),
Re: map vs. list-comprehension
Mandus wrote: jepp - faster, but still slower than the map. 100 iterations: zip+list-comprehension: 8.1s izip+list-comprehension: 7.5s map: 7.0s Strange. On 2.4.1 izip is the fastest. The thing is that if you put benchmark code in global the results are not fair as each variable access is a LOAD_GLOBAL and costs a dictionary lookup. That can lead to wrong results, like that 'try ... except ..' is faster than 'if i in ..'. With this benchmak: # from itertools import izip from time import time def f1(): return map(lambda bb,ii,dd: bb+ii*dd,b,i,d) def f2(): return [ bb+ii*dd for bb,ii,dd in zip(b,i,d) ] def f3(): return [ bb+ii*dd for bb,ii,dd in izip(b,i,d) ] def run(f, K): t0 = time () for i in xrange (K): f() return time()-t0 T = 200 def BENCH(K): global b, i, d N = T/K print %i times tuples of size %i: % (K,N) b = tuple (range(0, -N, -1)) i = tuple (range(N)) d = tuple (N*[1]) for x, y in sorted ([(run (x1,K), y1) for x1, y1 in ((f1,'map'),(f2,'zip'),(f3,'izip'))]): print '%s: %.2f' %(y,x), print BENCH(20) BENCH(2) BENCH(2000) BENCH(200) BENCH(20) BENCH(1) # On 2.4.1 I get: python zipmap.py 20 times tuples of size 10: izip: 1.32 zip: 1.50 map: 1.60 2 times tuples of size 100: izip: 1.00 zip: 1.14 map: 1.29 2000 times tuples of size 1000: izip: 0.94 zip: 1.10 map: 1.28 200 times tuples of size 1: izip: 0.93 map: 1.29 zip: 1.51 20 times tuples of size 10: izip: 0.96 map: 1.31 zip: 2.28 1 times tuples of size 200: izip: 0.96 map: 1.33 zip: 13.28 Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop until condition is true
Michael Hoffman wrote: Stelios Xanthakis wrote: Magnus Lycka wrote: Right. Silly me. Maybe in some future Python version, True and False will be constants, like None is since Python 2.4. Actually, there is support in marshal to write True and False objects so I don't understand why this isn't in 2.4 Because it would break existing code. Yes. Code that has variables named 'True' and 'False'. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Loop until condition is true
Magnus Lycka wrote: Konstantin Veretennicov wrote: On 6/21/05, Magnus Lycka [EMAIL PROTECTED] wrote: I don't know anything about the Python compiler internals, but it doesn't seem very hard to identify simple literals following while and if, and to skip the runtime test. (Perhaps it's done already?) True doesn't seem to be a literal, it is looked up by name and can be rebound to, say, 0 anytime: Right. Silly me. Maybe in some future Python version, True and False will be constants, like None is since Python 2.4. Actually, there is support in marshal to write True and False objects so I don't understand why this isn't in 2.4 Anyway, if you can't wait for 2.5 either use 'while 1:', or pyc[1] Stelios [1] http://students.ceid.upatras.gr/~sxanth/pyc/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Hi Michael [...] Releasing open source means that people *may* fix their own bugs, or abandon the code. [...] I agree with all the points made. Moreover let me add that code is one expression of a set of good ideas, and ideas want to be free! ;) I've decided to release the source code of pyvm as soon as it's ready. Right now *it doesn't* make much sense to give the source because it is still at an early development stage. Even if I did and people sent patches they wouldn't apply because I still make big changes to the architecture of it. I'd like to keep it in this status where I can modify the structure of the program until it becomes really developer-friendly. And IMO it doesn't make sense to release incomplete open source projects: either give something that's good and people can happily hack, or don't do it at all. Giving out the source of an unstable project will most likely harm it (see CherryOS incidents). The bottomline is that I estimate that pyvm will be ready within the summer. Thanks, Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Hi, Kay Schluehr wrote: Why this? eval() consumes a string, produces a code object and executes it. Wether the code-object is bytecode or a chunk of machine code makes a difference in the runtime but does not alter the high level behavioural description of eval(). In either way the compile() function behind eval is a JIT. It makes a difference because 1) You depend on a compiler. Especially if you want to optimize the machine code you depend on a big program (no tcc for example) 2) Optimizing machine code, needs a lot of code/time. 3) What about debugging info? Dwarf? 4) What if there's a new architecture? The bytecode compiler is *much* faster to produce the bytecode assembly. Also, for the other part of the thread, I think that bytecode may be in fact faster than machine code JIT. Here is a theory: Suppose that for each algorithm there is the ideal implementation which executes at the speed limit where it can't be done any faster. For small algorithms the speed limit may be known but for more complex programs, it's just a theoretical limit. Now for such very big programs bytecode has the advantage that it achieves very good code re-use; everything is those 400kB of the libpython core and that does not increase with the size of the program. In this case, bytecode is the driver that operates the buldozer (the buldozer being C). So the theory is that for very complex programs a bytecode+core-library is closer to the ideal implementation than a JIT which produces/compiles megabytes of machine code. Evidence for that may be that all those JIT efforts don't get any great speed ups (psyco is different as it exposes static-ness). Of course, if we care about speed we'll use Pyrex to convert some heavy routines to C. For example if we need FFT, it's madness to do it in the HLL. Make it part of the buldozer. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Armin Steinhoff wrote: pyvm has that. A big part of it is written in lightweight C++ [1]. Realy ? I have downloaded the lwc distribution and checked it out. It was a surprise that none of the examples are working. I'm using SuSE 9.0 with gcc 3.3.1 ... :( Is there a working version of lwc ??? pyvm is written in lwc-2.0 which is not yet released because nobody's using it. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Stelios Xanthakis wrote: Also, for the other part of the thread, I think that bytecode may be in fact faster than machine code JIT. Forgot to add: It depends of course on how good is the bytecode. IMO Python's bytecode is pretty good for its purpose which is executing a dynamic language with dynamic types and namespaces. Also, inside pyvm some things are done with internal bytecode objects. One such thing is list(generator). It has been proved that doing this in bytecode is faster than C. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Armin Steinhoff wrote: Is there a working version of lwc ??? pyvm is written in lwc-2.0 which is not yet released because nobody's using it. As you mentioned it ... lwc-2.0 is used for pyvm. So it is used :) Do you have an idea when lwc-2.0 will be releast ? Everyone who are interested in pyvm will need it ... It will be included together with pyvm. Normally if you want to just compile pyvm you do not need lwc, it's a preprocessor that generates C from C++ and the C for pyvm will be pre-generated. You'd need lwc for modifying/hacking pyvm. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Kay Schluehr wrote: Yes. What we are seeking for and this may be the meaning of Armins intentiously provocative statement about the speed of running HLLs is a successor of the C-language and not just another VM interpreter that is written in C and limits all efforts to extend it in a flexible and OO-manner. Python is just the most promising dynamic OO-language to follow this target. Bytecode engine is the best method for dynamic code execution (exec, eval, etc). A low level OOP language would be very suitable for a python VM. pyvm has that. A big part of it is written in lightweight C++ [1]. That makes it less portable as the lwc preprocessor is using GNU-C extensions. However, it's the same extensions also used by the linux kernel and AFAIK the intel compiler supports them too. So probably the bigger competitor of pyvm is boost-python. And that's one reason the release of the source is stalled until it gets better. Stelios [1] http://students.ceid.upatras.gr/~sxanth/lwc/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Roger Binns wrote: I am not very interested on C compatibility. That will rule out all the gui frameworks, SSL, cryptography and numerous other packages. Have a look at what happened to Prothon. What ultimately killed it was the problem of having a decent library. You don't have to make the C library compatibility totally high performance, but having any form of it there will make adoption by others easier. There are two kinds of C modules: those that do have a knowledge of the C API (like sre, tkinter, etc) and those that are just C/C++ libraries which are simply wrapped as modules. For the latter there are two solutions besides adding a wrapper which makes pyvm appear as libpython: - an advanced ctypes module which will make dlopening libraries and wrapping their symbols behind python functions, a matter of python code. I'm considering this approach to provide things like 'raw_input'. - hacking SWIG. Shouldn't be too hard and will instantly give us access to wx, qt, etc. The thing is that the C API of pyvm is IMHO superior and much more fun. You can wrap the entire sockets module in a couple of hours and also enjoy it. I wish I could clone myself to port the entire std library to pyvm -- so much fun it is:) thanks, Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Paul Rubin wrote: I hope that PyPy will replace CPython once it's solid enough. Trying to stay backwards compatible with the legacy C API doesn't seem to me to be that important a goal. Redoing the library may take more work than the Prothon guy was willing to do for Prothon, but PyPy has more community interest and maybe can attract more resources. I didn't know much about PyPy. It seems that pyvm is *exactly* what pypy needs to boost its performance. Does pypy has the vm in python as well? Does pypy have a compiler that produces 2.4 bytecodes? I think the next step in speeding up python (not that it's slow, I'm in the group of people that don't think Python is slow), is the AST compiler. An AST compiler for CPython is in the works AFAIK, but it would be more powerful in written in python. It would be also easy to have 'alternative' compilers that, for example are not whitespace sensitive, or the code looks like perl :), but they all produce python bytecode. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Kay Schluehr wrote: could You tell us a bit more about Your motivation to create an alternative C-Python interpreter? There is AFAIK no such ambitious project that has ever survived. The last one I remember died shortly after it was born: The motivation is that I just needed some bytecode engine. I deciced to go with python bytecode, because well, IMO it's the best! Eventually it turned out what it is. I'm afraid this may end up dead before unborn too. So it depends what people want. If nobody cares, I just learned python the hard way and the project does to the abandonware cemetary. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
[EMAIL PROTECTED] wrote: This project is probably a LOT of work; maybe people can tell us about such efforts *before* doing so much work, so we can discuss it, and avoid wasting time. It is a lot of work indeed. Usually, when people announce we shall create X, it doesn't happen. And you don't know if you can do it at all *before*. Maybe you can explain us why it is so fast, and/or maybe you can work with the other developers to improve the speed of the normal CPython, this can require equal or less work for you, and it can produce more long-lasting results/consequences for your work. The reason is that it's built from the scratch. Guido would disagree with that, see py-dev thread: http://www.mail-archive.com/python-dev@python.org/msg01225.html There *are* alternative ways to do some things in the vm and Joel is simply wrong:) Could this be Python 3000!!!? :) Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: pyvm -- faster python
Roger Binns wrote: could You tell us a bit more about Your motivation to create an alternative C-Python interpreter? I'd also be curious to know if the performance gains would remain once it gets fleshed out with things like closures, long numbers, new style classes and a C library compatibility shim. I guess it will. There are several places with /*XXX:speed up*/ and a couple more ideas to gain exrta speed. On the other hand pyvm does not check for Bad Internal Calls and other checks Cpython does to be OK in all cases (for example if __cmp__ modifies a list while it's being sorted, in pyvm you *can* get a crash). There is no plan to implement closures; unless there is a way to turn closures to default arguments with bytecode hacking. But yes, closures are interesting, especially in generator expressions and lambdas. I am not very interested on C compatibility. Once the source is open people can implement it if they want but I'd rather go with an advanced ctypes module which will make loading dynamic libraries a matter of python code. Stelios -- http://mail.python.org/mailman/listinfo/python-list
pyvm -- faster python
Hi. pyvm is a program which can run python 2.4 bytecode (the .pyc files). A demo pre-release is available at: http://students.ceid.upatras.gr/~sxanth/pyvm/ Facts about pyvm: - It's FAST. According to the cooked-bench benchmark suite it finishes in 55% of the time python takes;) - It's SMALL. Currently the source code is under 15k lines with the builtin modules. - It's new. Uses no code from CPython. - It's incomplete. Not even near the stability and quality of python. It needs A LOT of work before it can be compared to CPython. Moreover, at the time it lacks many things like closures, long numbers new style classes, etc. - It's incompatible with CPython. Not all programs run. - The C API is incompatible. You can't run C modules (a thin wrapper to make pyvm appear as libpython *could* be possible but not a goal AFAIC) - The demo is an x86/linux binary only. You shouldn't trust binaries, run it in a chrooted environment not as root! Hope it works! Cheers, Stelios -- http://mail.python.org/mailman/listinfo/python-list
ANN: Python benchmark suite
Hi I'd like to announce the pyvmbench benchmark suite which is designed to evaluate different python implementations, different versions of the same implementation and different compilers/compilation flags for the same version of a python implementation (same). If you want, you can of course benchmark Jython on Mac vs IronPython on XP! It is located right here: http://students.ceid.upatras.gr/~sxanth/pyvm/pyvmbench.tar.bz2 I've taken code from the computer language shootout, posts in c.l.py and other code from the internet which seems to be ok to use. Hopefully we should be ok. Ok, the testcases are not many but they are all real programs that do real jobs and this makes their results at least, realistic:) Cheers, Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for Benchmarklets to improve pyvm
coffeebug wrote: Newbie here (new to the language and scripting in general). I'm trying to figure out what you mean by bytecode. Do you mean a virtual python environment that can be hosted by any anonymous operating system? For example, you want to run Python programs on BEOS so you crank up its version of PYVM and load a Python source code and run it? The pyc files. See module 'compile' and module 'dis'. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for Benchmarklets to improve pyvm
Skip Montanaro wrote: Take a look around for Marc Andre Lemburg's pybench suite. Thanks! Although pybench needs module.re and module.pickle, so I'll post results later. Moreover, I have similar tests. I'd prefer scripts that do *real* calculations. Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I play too?
Scott David Daniels wrote:
if __name__ == '__main__':
import sys
main(sys.argv[1:] or ['anagrams.py'])
This is *exactly* the kind of testcases I'm looking for to test
the soon-to-be-released pyvm. Great! I'll be back with results.
For now, a fast anagrams.py is
--
import sys
WORDS = [ i.rstrip () for i in file ('/usr/share/dict/words') ]
def findana (anagram):
sorted_anagram = sorted(anagram.lower())
len_anagram = len (anagram)
found = [ word for word in WORDS if len(word)==len_anagram and
sorted(word)==sorted_anagram ]
print Anagrams of %s: %s % (anagram, ' '.join(found))
for i in sys.argv [1:]:
findana (i)
-
And timings
time python anagram.pyc stop step words lots pool eat fast slow lamp
cold door xyzzy
Anagrams of stop: opts post pots spot stop tops
Anagrams of step: pest pets sept step
Anagrams of words: sword words
Anagrams of lots: lost lots slot
Anagrams of pool: loop polo pool
Anagrams of eat: ate eat tea
Anagrams of fast: fast fats
Anagrams of slow: lows owls slow
Anagrams of lamp: lamp palm
Anagrams of cold: clod cold
Anagrams of door: door odor
Anagrams of xyzzy:
real0m1.491s
user0m1.390s
sys 0m0.040s
time pyvm anagram.pyc stop step words lots pool eat fast slow lamp cold
door xyzzy
Anagrams of stop: opts post pots spot stop tops
Anagrams of step: pest pets sept step
Anagrams of words: sword words
Anagrams of lots: lost lots slot
Anagrams of pool: loop polo pool
Anagrams of eat: ate eat tea
Anagrams of fast: fast fats
Anagrams of slow: lows owls slow
Anagrams of lamp: lamp palm
Anagrams of cold: clod cold
Anagrams of door: door odor
Anagrams of xyzzy:
real0m0.923s
user0m0.760s
sys 0m0.070s
---
Stelios
--
http://mail.python.org/mailman/listinfo/python-list
Looking for Benchmarklets to improve pyvm
Hi. pyvm is a program that can run python 2.4 bytecode and most of the times produce the expected output. See http://students.ceid.upatras.gr/~sxanth/ I'm collecting small testlets to benchmark it, discover bottlenecks and improve it. They should be small and not use any crazy modules. Only [sys, os, itertools, thread, threading, math, random] for now. Basically, stuff that has appeared in c.l.py will be great (like xah lee's partition list be equivalence, etc) Send! Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: Big development in the GUI realm
Alex Martelli wrote: Dennis Lee Bieber [EMAIL PROTECTED] wrote: hassle to code, but if your application could dynamically select from whatever toolkit is available on the machine, you (and I should emphasis that this is an impersonal/generic you I reference) might be able to argue an exemption from the QT license. So maybe it's time to resurrect anygui, maybe in a simplified version which can only interface to, say, PyQt or Tkinter -- 'eithergui' maybe. Alex Done already: 'Twilight GUI'! http://students.ceid.upatras.gr/~sxanth/twgui/ However, it's very furstrating working on 4 toolkits in parallel and because some of the don't have good documentation, I'm doing other things right now:) Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: python-dev Summary for 2004-11-16 through 2004-11-30
[EMAIL PROTECTED] wrote: Would you like the source with your function? Yes, since I asked for this feature something like two years ago ;-) Well, the main objection seemed to be that we can get the source of a function one way or another. For functions with a file (1) with inspect , for functions defined dynamically with exec(2), by knowing what we pass to exec and storing it, and for functions defined in the interactive prompt (3), by using a higher level IDE/shell that is not the pure raw_input, but does sophisticated analysis of code fed to it and which will be responsible for storing functions (!!). Still I believe it's the job of the core python parser to get this info and attach it to function objects. The other problem was whether the source attribute should be saved to pyc files (or more generally marhsaled together with the function object). Logically it should. OTOH, for the application I had using this, I didn't need marshalling source because it stored all the code (initial functions + functions defined while the application was running) in python source form. So, I think that in practice one will use either bytecode or the __source__ feature and not both, but I can't prove it. 8) There's a PEP and an --ugly- patch for 2.3.4 +10 ? Stelios -- http://mail.python.org/mailman/listinfo/python-list
