Hi list,

today, I saw the shedskinner decorator by Brent Pedersen:
https://github.com/brentp/toolshed

With that, it's easy possible to compile only some functions with
shedskin, so it's not needed so write standalone *.py files and import
those functions all the time. Just add the decorator to it and you are
done.

Here is an example:
"""
from shedskin.decorators import shedskinner

@shedskinner((2, 4), (6, 12), long=True, random=True, wrap_around_check=False)
def adder(a, b):
    return a + b

print adder(6, 8)
"""

Please pull and test from here (branch name tmpdir_decorator), where
that's incorporated:
git://github.com/tomspur/shedskin.git tmpdir_decorator

Online view:
https://github.com/tomspur/shedskin/tree/tmpdir_decorator

Greetings,
     Tom

hi guys,

sorry for the delayed reply.

I had another look at this, and actually tried it out, and I have to
admit it's pretty sweet to have shedskin run semi-transparently in the
background.. :-)

otoh, I still don't really like the idea of adding declarations to
python code (it's the reason I started shedskin), and am also hesitant
to add in automagic code to avoid having to put 'adder' in a separate
file, which is not that difficult.. but this may be just me, being
somewhat obsessed with removing unneeded code from shedskin.. same
thing for the 'tmpdir' option.. :P

does anyone else have an opinion about this, and/or a strong desire to
see the decorator/tmpdir code go in..?

thanks,
mark.

On Sun, May 13, 2012 at 6:52 PM, Thomas Spura

--
http://www.youtube.com/watch?v=E6LsfnBmdnk

Full disclosure:  I am not really a Shed Skin user (I tried a
hello-world example or two several years ago and have not done
anything with it since then), but am very interested in the concept,
and I do not hesitate to recommend it to others.

Given that, if my opinions are still worth anything, here they are:

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 there may be other people like me (don't know how many,
though), who are comfortable with Python, and would certainly welcome
speed improvements, but are disinclined to fire up another tool to do
it.  PyPy probably comes closest to fitting the bill for this kind of
Python programmer.  But a decorator would improve the Shed Skin
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.

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
inelegant.

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.

John

+1, it's great to just add a decorator and don't need to move single
functions to an extra file and create a module of it there and import
it again.
(Which was my main reason for creating the pull request ;))

You already need those declarations already for creating the
standalone module (you just have them handy in the "if
__name__=='__main__'" section).
Adding it in a separate file is not difficult, but looks ugly, when
you deal with a bigger project and want to organize it differently.
Then you are forced to add it to another file and import it from there
again (not a big deal, just not so clear and nice as the decorator).
Hmm, while you are talking about "removing unneeded code": :P
52M     speed/testdata/stringies

+1 for removing unneeded code, but I wouldn't consider the
decorator/tmpdir as unneeded...
(See the mail of John about the Cython comparison)

Greetings,
    Thomas

hi john,

Upon looking at the examples, I had much the same reactions as Mark:

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
problem..

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
clear.. :P

picture noticeably.  If there is any doubt left whether Shed Skin or

I don't know. Cython still supports arbitrary libraries and compiles mixed
dynamic/static code.

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

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

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..

thanks again,
mark.