Upon looking at the examples, I had much the same reactions as Mark:
> It's really nifty to be able to integrate Shed Skin so easily, but it
> feels a little dirty.
I think perhaps it makes it look easier than it is.. :-) shedskin is just
not meant as a transparent tool that automagically optimizes your code.
that's pypy's goal, and it's a great goal to have. it's also not meant as a
tool where you simply add a few annotations to existing code - we have
cython for that. people who expect ultimate user friendliness (and may be
attracted by such a decorator, for example) will just bail out at the next
for me, shedskin's goal is to be a simple, transparent, system for making
python code run really, really fast, at the expense of restricing the
language and libraries and asking the programmer to put in some work.
the decorator probably needs quite a bit of further work as well. for
example, what if compiled functions call each other, or reach out into the
surrounding python code? at least a separate module keeps the boundaries
picture noticeably. If there is any doubt left whether Shed Skin or
> Cython is easier or more comfortable for this kind of programmer, the
> decorator probably removes that doubt in Shed Skin's favor.
I don't know. Cython still supports arbitrary libraries and compiles mixed
I personally hate to see type declaration based systems for Python, since
we can just profile types at run-time and optimize pretty well for those
(psyco, pypy..). it feels like a temporary solution. of course shedskin may
also just be a temporary solution. if pypy keeps getting faster, perhaps
there's no real point anymore.. shedskin was started in a time where psyco
was dead in the water, and producing much slower code than GCC ;-)
But like Cython, the way this decorator is currently implemented feels
> a bit like type annotation rather than automatic type inference.
> Supplying example values? That's actually even *less* intuitive to me
> than supplying the desired types. And it looks and feels clunky and
in case of a separate module we also need to somehow 'seed' the type
inference. something has to be called somewhere in order to know the
argument types.. if this something calls all other things, we only need the
initial call of course.
so I guess if one decorated function calls another function, the other
function wouldn't have to be decorated with example values since they are
supplied by the first..
In the end, I guess I am +0. The decorator, as implemented, probably
> would make things more convenient for some people, possibly to the
> point of converting some Shed Skin nonusers to users. Those who find
> the decorator useless or ugly can simply avoid it.
it does add bloat to shedskin itself of course, and cost me time in terms
of maintenance.. also if it doesn't work well right away, it may also cost
us users.. :P but again, I think it's perhaps a false promise. people may
be attracted by the convenience factor, only to find out shedskin is just
not a turn key solution.. :P (for example they'll start passing huge
arguments in and out, causing their code to go slower than using cpython
because of the intermediate conversion.. or they won't understand why they
can't change arguments from 'the other side'.)
so still a -1 from me at this point.. I very much appreciate the efforts of
course, but I'm not yet convinced to put this in..