[PULL] shedskinner decorator

[Thomas Spura]

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

[Mark Dufour]

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.

> --
> You received this message because you are subscribed to the Google Groups "shedskin-discuss" group.
> To post to this group, send email to shedskin...@googlegroups.com.
> To unsubscribe from this group, send email to shedskin-discu...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/shedskin-discuss?hl=en.
>



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

[John Yeung]

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

[Thomas Spura]

On Tue, May 29, 2012 at 1:16 AM, Mark Dufour <mark....@gmail.com> wrote:
> 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.. :-)

+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 ;))

> 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

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

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

+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

[srepmub]

hi john,

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

thanks again,
mark.