I have just released Shed Skin 0.0.23. It doesn't contain the type inference scalability improvements I was working on, but it does have quite a few bug fixes and minor feature additions. Here's a list of changes:
-support for __iadd__, __imul__ and such (except __ipow__ and __imod__)
-some overdue set optimizations
-fix for string formatting problem (%% did not always work)
-extension module stability fixes
-fix for particular inheritance problem
-other minor bugfixes, cleanups, and error messages
I could really use some systematic help in pushing Shedskin further. Some ideas:
-send in bug reports - these are extremely valuable and motivating to me, yet I don't receive many..
-find out why test 148 is currently broken under windows
-add datetime, re or socket support
-look into supporting custom classes in generated extension modules
-write a Shedskin tutorial for 'novice' programmers
-systemically test performance and suggest and work on improvements
-investigate replacements for std::string and __gnu_cxx::hash_set
-perform janitorial-type work in ss.py and lib/builtin.?pp
-support extension modules under OSX (OSX gives me accute mental RSI)
-add more tests to unit.py
6 comments:
Open source development can sometimes be unrewarding, so I just wanted to leave some encouragement to keep up the good work.
Shed Skin is great stuff, and I'm particularly excited about being able to write extension modules with it.
I read in the mailing list that you want to make Shed Skin a strict python interplote experiement, but I'm still wondering if it can be made into be a 'python like language that compiles.'
The idea that I think really helpful and 'innovation' is that the compiler will always compiles but restore to libpython when it found something it does not recognize.
Now, this part is not so innovative as pyrex pretty much just does that. What's innovative is that when using libpython, the compiler also tell the developers which part of the source code it cannot interplore.
Then the developer can use some annotatons to 'Fix' the variables or whatever to has the compiler compile better next cycle.
So we have 'error', 'warning' and 'confusing' spit out at compile time.
I think this is a more practical approach and no one was working in this direction yet.
A 'compiler assistant developing model'. :)
I hope with compiler's help, it's easier to wrap all the standard library and ship a libpython-std.so with all the std python library compiled. Wow!
I'm interested in string classes. What's the problem with std::string? Unicode compliance? Maybe one could investigate glib::ustring then.
I'm not interested in unicode, just raw performance for ascii strings.
here you can see how std::string performs against some other string implementations:
http://bstring.sourceforge.net/features.html
it seems std::string is just not that optimal, especially for short strings.
this is why I recently added 1-length string or 'character' caching to Shedskin CVS. this makes some simple test programs dramatically faster.
but I really haven't done much benchmarking of string performance, so I can't say how much of the perceived problem this solves..
@ha:
compile-time type inference becomes much more difficult or even impossible in a context where you allow all sorts of dynamic things to happen at run-time. consider a program that replaces 'list' by something else..
if you cannot prove even simple things about a program at compile-time, it becomes almost impossible to optimize any part of it, even if it looks trivial.
so to optimize things (at compile-time), it's clear we have to restrict Python in some ways. I think it's intuitive and transparent to just require static typing, and to combine dynamic and compiled code via extension modules.
Post a Comment