Re: Shed Skin Python-to-C++ compiler 0.0.23
> Adding socket support would certainly open the door for many common > classes applications. If I had my pick, I say, sockets and then re. Thanks. Especially sockets should be not too hard to add, but I probably won't work on these directly myself. Let me know if you are interested.. :-) > BTW, I gatta say projects like shedskin and pypy are the most exciting > python projects I'm aware of. Please keep of the good work. I'm so > excited about the day I can begin using shedskin for the types of > projects I use python on. I'm practically working alone on Shedskin, so the better bet will be PyPy, unless I start getting more help. BTW I usually add a link to the homepage, but somehow I forgot this time: http://mark.dufour.googlepages.com Thanks! Mark Dufour. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Compyler 0.1
> + Generates C++ so you need an intermediate compiler (probably only > an issue on windows) Shed Skin comes with a stripped down MingW/G++, so compiling and running/importing compiled code is as easy as 'ss blah.py; make run' or 'ss -e blah.py; python; import blah' under both Windows and Linux (in theory, of course). Mark Dufour (Shed Skin author). -- http://mail.python.org/mailman/listinfo/python-list
Re: c.l.py dead, news at 11 (was Re: Mangle function name with decorator?)
> > Its kind of sad to see unladen swallow, which is just > > a promise, on the list, whileShedskin, which isn't, > > is ignored. > > > Does this say something about big corporations > > vs the small man? > > I think the programs on the list were supposed to actually implement > Python and extensions of Python, but not incompatible dialects. > Otherwise Pyrex (for example) would also be on the list. for the record, the input for Shedskin is pure Python, so there is no added syntax or optional type declaration system. that said, I can understand it not being on some list for not being production-ready. thanks, mark dufour. -- http://mail.python.org/mailman/listinfo/python-list
Re: c.l.py dead, news at 11 (was Re: Mangle function name with decorator?)
On Mar 30, 4:36 pm, Michele Simionato wrote: > On Mar 30, 3:31 pm, srepmub wrote: > > > for the record, the input forShedskinis pure Python, so there is no > > added syntax or optional type declaration system. that said, I can > > understand it not being on some list for not being production-ready. > > > thanks, > > mark dufour. > > But doesShedSkinaccepts all valid Python constructs? > I thought there were restrictions. there are certainly several important restrictions, but what I meant was that if it works with Shedskin it is also valid Python code, and there are no hidden type declarations or hints hidden in docstrings and such. thanks, mark dufour. -- http://mail.python.org/mailman/listinfo/python-list
Shed Skin (restricted) Python-to-C++ Compiler 0.0.28
Hi all,
I have just released Shed Skin 0.0.28, with the following changes.
Thanks to those mentioned for helping out!
- basic 'socket' support (Michael Elkins)
- support for os.{popen3, popen4} under UNIX (Jaroslaw Tworek)
- support for time.strptime under Windows (David Marek)
- options for changing output dir, disabling annotation (Dave Tweed)
- support for 'cmp' and 'reverse' arguments of 'sorted' and
'list.sort'
- fixes for cross-module default arguments
- important fixes for type inference and inheritance
- restore compatibility with Python 2.3
- many minor bugfixes
I would really like to receive more bug reports. Please try out the
new version, and let me know about any problems.
With the socket support, 15 common modules are now largely supported.
For a 0.1 release, I'd really like to have support for one more
module: datetime. Thanks to the GHOP, there is a type model already
(lib/datetime.py), so we only still need a C++ implementation..
http://shedskin.googlecode.com
Thanks,
Mark Dufour.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Native Code vs. Python code for modules
> ShedSkinwill probably have scaling problems: as the program size > grows it may need too much time to infer all the types. The author has > the strict policy of refusing any kind of type annotation, this make > it unpractical. well, I admit I really don't like manual type annotations (unless for documentation purposes). it seems a much nicer (..pythonic) approach to just get type information from a profiler. if I had four hands (and two brains), shedskin would probably already include one. that said, I know of several ways to improve the scalability shedskin's type analysis itself, and I might still pursue those. but I think, in combination with a profiler, things should scale pretty well already.. certainly enough to compile most smallish programs/extension modules of up to a few thousands lines. > And, despite your interest inShedSkin, so far very few people have > given a hand actually developing SS (I think partially well, it's been quite a few people actually, about 15 that have contributed substantial improvements. of course doing a compiler like this is probably more than 10 person-years of work, so I could always use more help. becauseShedSkinPython sources aren't much hackable. This is very bad for an > OpenSource project), so I think the author now has lost part of the I think they are reasonably hackable for the most part, and this can only improve. in the beginning I had little documentation, and there was just this 7000-line Python file :-) now things are more split up, and I even added documentation recently to each part. yes, type inference will always be hard to hack on, but that's only one part. the C++ side, where I can arguably use most help, and which consists of more than half of the code, has always been easily hackable. > will to develop this project (but probably we'll see one of two more > versions). I have my ups and downs of course, but at the moment I'm quite enthousiastic about the whole thing, in part because people are actually contributing. a new release is coming up, with support for datetime and ConfigParser among many other improvements/fixes, and there is a much faster set implementation in the pipeline. at the moment, I have no plans to halt development at all. > For me so far the most viable way to produce a faster Python system > seems a version of CPython with Cython and something Psyco-like built- > in (and a built-in compiler on Windows, like MinGW 4.2.1), maybe with > some syntax support in the Python language, allowing to mix statically > compiled Python code with dynamically compiled Python code in an easy > way (as CLisp sometimes does). shedskin can of course generate extension modules (shedskin -e), that can be imported from larger Python programs. it's a bit clumsy, as only builtins can be passed to/from shedskin, and everything (args, return values) is copied recursively, but it can be quite useful already. and of course it can only improve as well.. mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin (restricted) Python-to-C++ compiler 0.0.29
> Not to sound negative, but what's with the 0.0.x version numbers ? > Maybe it's just me, but seeing a zero major/minor version give me the > impression of experimental/pre-alpha project, which (from my very > limited knowledge) doesn't do justice to shedskin's current state. I know of too many bugs to be comfortable calling it 0.1 just yet.. And I really want to improve extension module support (as mentioned) first. There's not much else holding back a 0.1 release. Thanks, Mark. -- http://mail.python.org/mailman/listinfo/python-list
interval arithmetic libraries
Hi all, I'm looking for libraries that allow one to calculate with sets of (date) intervals. So for example, I'd like to be able to calculate the overlap between two sets of intervals, the union etc. Preferrably, this works with datetime objects, is written in pure Python, and has reasonably good (algorithmic) performance. The neatest library I've found so far is this one: http://members.cox.net/apoco/interval/ >From an API standpoint, it looks rather nice, but the performance could be better (for example, calculating an overlap now involves looping quadratically over both interval sets), and it doesn't work fully with datetime objects (Inf doesn't work). Thanks for any pointers, Mark Dufour. (author of Shedskin, an experimental (restricted-)Python-to-C++ compiler, http://shedskin.googlecode.com) -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Shed Skin 0.2, an experimental (restricted) Python-to-C++ compiler
> Nice timings, can you please show me the Python, Java and C code > versions? I may do more tests. also, which shedskin options did you use? did you use -bw, to disable bounds and wrap-around checking? this can make quite a difference for code that does a lot of indexing. if the code uses random numbers, then -r can also make a big difference, to use C rand(), instead of Python compatible random numbers. and which C++ compiler flags did you use? the default -O2, or something like -O3 -fomit-frame-pointer -msse2..? thanks, mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Shed Skin 0.2, an experimental (restricted) Python-to-C++ compiler
> With -bw and -O3 -fomit-frame-pointer -msse2 i have 5.5s (instead of 8) > > Let me know if you find better. thanks. now I'm wondering how fast does the C version become with these flags..? :-) mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Shed Skin 0.2, an experimental (restricted) Python-to-C++ compiler
please send any program that doesn't work with shedskin (it still is experimental after all) to me, or create an issue at shedskin.googlecode.com, and I will have a look at the problem. thanks, mark. -- http://mail.python.org/mailman/listinfo/python-list
