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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 durin
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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
