luke.leighton at googlemail.com
Mon Sep 21 00:03:23 CEST 2009
On Sep 20, 12:05 am, exar... at twistedmatrix.com wrote:
> the same behavior?
that's one of the sub-goals of the pyjamas project, yes.
> I don't intend to imply that it doesn't - I haven't
> been keeping up with pyjamas development, so I have no idea idea. I
> think that the case *used* to be (perhaps a year or more ago) that
> pyjamas only operated on a fairly limited subset of Python. If this was
> the case but has since changed, it might explain why some people are
> confused to hear pyjamas called a Python implementation now.
yup. "-O" now equals [roughly] pyjamas 0.3 to 0.5p1 behaviour, aka
since kees joined, he's been steaming ahead with python
interoperability (--strict option). he first started out by improving
the pyjamas compiler and support libraries to the point where the
as-is, and it's gone from there, really.
on the roadmap is to take a look at what the unladen/swallow team
have done, when they get to their stage 2 "unboxing", and see if
calling out to PyV8 or Python-SpiderMonkey objects can be done from
intobject.c, longobject.c etc.
if the early experiments are anything to go by, python will then have
_yet another_ python accelerator.
but, really, for that to properly happen, python has _got_ to get
some type-checking decorators on functions:
@paramtypecheck(foo=int, bar=[int, str])
@paramtypecheck(int, [int, str]) # or this
def randomfunction(foo, bar):
if isinstance(bar, str):
bar = int(bar)
return foo + bar
this kind of type-checking guidance would _drastically_ help out all
of the compilers (such as that python-to-c++ one), and could probably
also be utilised by http://python.org itself, ultimately, to speed up
it's also just good software engineering practice to check parameters
and return results.
More information about the Python-list