Re: [Python-Dev] pypy-0.9.0: stackless, new extension compiler
Congratulations! [EMAIL PROTECTED] wrote on 25/06/2006 13:07:01: The PyPy development team has been busy working and we've now packaged our latest improvements, completed work and new experiments as version 0.9.0, our fourth public release. The highlights of this fourth release of PyPy are: **implementation of stackless features** We now support the larger part of the interface of the original Stackless Python -- see http://www.stackless.com for more. A significant part of this is the pickling and unpickling of a running tasklet. These features, especially the pickling, can be considered to be a technology preview -- they work, but for example the error handling is a little patchy in places. **ext-compiler** The extension compiler is a new way of writing a C extension for CPython and PyPy at the same time. For more information, see its documentation: http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html **rctypes** Most useful in combination with the ext-compiler is the fact that our translation framework can translate code that uses the standard-in-Python-2.5 ctypes module. See its documentation for more: http://codespeak.net/pypy/dist/pypy/doc/rctypes.html **framework GCs** PyPy's interpreter can now be compiled to use a garbage collector written in RPython. This added control over PyPy's execution makes the implementation of new and interesting features possible, apart from being a significant achievement in its own right. **__del__/weakref/__subclasses__** The PyPy interpreter's compatibility with CPython continues improves: now we support __del__ methods, the __subclasses__ method on types and weak references. We now pass around 95% of CPython's core tests. **logic space preview** This release contains the first version of the logic object space, which will add logical variables to Python. See its docs for more: http://codespeak.net/pypy/dist/pypy/doc/howto-logicobjspace-0.9.html **high level backends preview** This release contains the first versions of new backends targeting high level languages such as Squeak and .NET/CLI and updated versions of the JavaScript and Common Lisp backends. They can't compile the PyPy interpreter yet, but they're getting there... **bugfixes, better performance** As you would expect, performance continues to improve and bugs continue to be fixed. The performance of the translated PyPy interpreter is 2.5-3x times faster than 0.8 (on richards and pystone), and is now stable enough to be able to run CPython's test suite to the end. **testing refinements** py.test, our testing tool, now has preliminary support for doctests. We now run all our tests every night, and you can see the summary at: http://snake.cs.uni-duesseldorf.de/pypytest/summary.html What is PyPy (about)? PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, memory and threading models are to become aspects of the translation process - as opposed to encoding low level details into the language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. PyPy is partially funded as a research project under the European Union's IST programme. Where to start? - Getting started:http://codespeak.net/pypy/dist/pypy/doc/getting- started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.9 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals - The Just-in-Time compiler and other performance improvements will be one of the main topics of the next few months' work, along with finishing the logic object space. Project Details --- PyPy has been developed during approximately 20 coding sprints across Europe and the US. It continues to be a very dynamically and
Re: [Python-Dev] Visual studio 2005 express now free
[EMAIL PROTECTED] wrote on 25/04/2006 13:22:27: Neil Hodgson [EMAIL PROTECTED] writes: Martin v. Löwis: Apparently, the status of this changed right now: it seems that the 2003 compiler is not available anymore; the page now says that it was replaced with the 2005 compiler. Should we reconsider? I expect Microsoft means that Visual Studio Express will be available free forever, not that you will always be able to download Visual Studio 2005 Express. I don't think that's what Herb Sutter said in his ACCU keynote, which is where I'm pretty sure Guido got his information at the start of this thread (he was there too and the email appeared soon after). If I remember right, he said that 2005 was free, forever, and they'd think about later versions. I may be misremembering, and I certainly haven't read any official stuff from Microsoft... Hi Michael, I was there and that's how I remember it too. Cheers, Ben Cheers, mwh -- I also feel it essential to note, [...], that Description Logics, non-Monotonic Logics, Default Logics and Circumscription Logics can all collectively go suck a cow. Thank you. -- http://advogato.org/person/Johnath/diary.html?start=4 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python- dev/python%40theyoungfamily.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
[EMAIL PROTECTED] wrote on 30/03/2006 11:38:30: Jack Diederich wrote: Classes have a unique property in that they are the easiest way to make little namespaces in python. For a while now, I've been wondering whether it would be worth having a construct purely for creating little namespaces, instead of abusing a class for this. I've been thinking about an 'instance' statement that creates an instance of a class: instance my_thing(MyClass): # attribute assignments go here Maybe this would be a use for the proposal a while back where: 'statement' name(args): ... implied name = 'statement'(name, args, namespace) then we could have: namespace foo: ... and interface IFoo(IBar): ... and your instance my_thing(MyClass): ... ? Cheers, Ben -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python- dev/python%40theyoungfamily.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] any support for a methodcaller HOF?
Michael Hudson wrote on 03/02/2006 09:36:30: Hmm. funcTakingCallback(lamda x:x.method(zip, zop)) funcTakingCallback(methodcaller(method, zip, zop)) I'm not sure which of these is clearer really. Are lambdas so bad? (FWIW, I haven't internalized itemgetter/attrgetter yet and still tend to use lambdas instead those too). A class I wrote (and lost) ages ago was a placeholder class, so if 'X' was an instance of this class, X + 1 was roughly equivalent to lambda x:x+1 and X.method(zip, zop) was roughly equivalent to your methodcaller(method, zip, zop). I threw it away when listcomps got implemented. Not sure why I mention it now, something about your post made me think of it... The C++ library Boost makes use of this method, but has a number of placeholder variables _1, _2, _3 ... _9 which can be combined to form expressions. e.g _1 + _2 is the same as lambda x,y: x+y so maybe there could be a lambda module that exposes placeholders like this. Pythons ones will be better that the C++ ones because we would be able to delay function calls as above with a much nicer syntax than the C++ versions. E.g _1.method(_2+_3) ! Cheers, Ben Cheers, mwh -- If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. -- Guy L. Steele Jr, quoted by David Rush in comp.lang.scheme.scsh ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python- dev/python%40theyoungfamily.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
