1) Cython has a nice feature called pyximport that lets you easily compile and run Cython code from within CPython without precompiling the Cython. Very convenient. It would be great if shedskin had that!

2) Maybe shedskin already works this way, but it's not clear to me so I'll bring it up. If shedskin's native structures could be made threasafe, then shedskin could theoretically be arranged such that entry into shedskin code would mean it could ignore the GIL. (I believe I mentioned this possibility some time ago, as well.) In that case, the ability of shedskin extensions to speed CPython code could theoretically be multiplied by the number of cores. Especially with the addition of a pyximport-like feature, making the shedskin extensions more painless to work with.

3) Anything you can do to improve ss's ability to run unmodified python code. So far, when I've used ss, there have generally been times when I've had to modify my python code to make it easier for ss to infer types. The loss modifications that are needed, the better.

4) The last suggestion is: anything you feel would be required to make available a clearly-labeled "stable" release. I've had some cases of getting wrong results from shedskin, and communicating them to you, and seeing you quickly fix the root cause. That's fantastic, and really appreciated! It's an "experimental" package, and as such, it's great, and your responsiveness has been great. But a stable release, even with limited (though well-defined) functionality, would probably get a good amount of uptake.

Best,
Gary

Following up on my previous msg (below the line), I'll just mention that lately I've been using pyprocessing/multiprocessing a lot so I don't perceive the issue of the GIL as being as important as I once did. Still, if you're operating with huge amounts of data, as I often do, it can be helpful to have large shared (native python) data structures, and for that threading is still quite nice.

========================================

1) Cython has a nice feature called pyximport that lets you easily compile and run Cython code from within CPython without precompiling the Cython. Very convenient. It would be great if shedskin had that!

2) Maybe shedskin already works this way, but it's not clear to me so I'll bring it up. If shedskin's native structures could be made threasafe, then shedskin could theoretically be arranged such that entry into shedskin code would mean it could ignore the GIL. (I believe I mentioned this possibility some time ago, as well.) In that case, the ability of shedskin extensions to speed CPython code could theoretically be multiplied by the number of cores. Especially with the addition of a pyximport-like feature, making the shedskin extensions more painless to work with.

3) Anything you can do to improve ss's ability to run unmodified python code. So far, when I've used ss, there have generally been times when I've had to modify my python code to make it easier for ss to infer types. The loss modifications that are needed, the better.

4) The last suggestion is: anything you feel would be required to make available a clearly-labeled "stable" release. I've had some cases of getting wrong results from shedskin, and communicating them to you, and seeing you quickly fix the root cause. That's fantastic, and really appreciated! It's an "experimental" package, and as such, it's great, and your responsiveness has been great. But a stable release, even with limited (though well-defined) functionality, would probably get a good amount of uptake.

Best,
Gary

hi again gary,

thanks for your suggestions!

there were also some comments on my blog about integration with
distutils. but as much as I agree with such ideas, I'm afraid I will
have to rely on contributions for other people to turn them into
reality. packaging is just not my cup of tea.. it's a miracle there's
actually a windows version of Shedskin :-)

yes, the topic comes up now and then :) I think at the moment, quite a
few parts of Shedskin's C++ library are not thread-safe. but I've
personally never used threads (love multiprocessing though), so again
I don't think I'd be the person to look into this.. ;)

I'm guessing the type inference techniques in shedskin can still be
improved by a lot, but there will probably always be scalability
issues. type inference is a really hard problem.

something that would really help here is a 'type profiler', so the
type inferencer can start with a reasonable estimate of (or lower
bound on) types, making its job dramatically easier, and opening the
door to compilation of programs into the thousands of lines of code.

I can be motivated in this area by receiving nice test cases such as
minilight and disco, although I probably won't start on a profiler
anytime soon.

I totally agree, and I'm committed to stabilizing the feature set (as
described in the tutorial) of the 0.2 version. but I could really use
more bug reports to speed up this process and to keep me motivated to
do all this grunt work..

thanks,
mark.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson