> -support for itertools (thanks to the work of jeremie)
jeremie, I'm hoping to see another patch soon.. ^^ I'd be happy to
help out if you don't have time to fully complete it, now that most
other things on this list have been tackled. anyway, jeremie and I
sorted out most issues, and I think we can support practically
everything..
> -support for csv (by eating our own dogfood, using something like
> python-dsv - thanks chris)
I wrote a pure Python implementation based on _csv.c (and csv.py) from
CPython, and compiled it using shedskin (see csv15.py). I decided not
to support Sniffer for now, or custom Dialects, but most basic things
should work now.
> -if we support itertools, then I guess 'map'/'filter'/'reduce' should
> work too (yes, I give up my opposition :))
these have been added.. I also added support for passing around
builtin callables, which required a bit of surgery.. so the following
now works, for example:
print sorted([[2,3,4], [5,6], [7]], key=len)
print map(len, ['a','bc'])
print map(max, ['a','bc'], ['d'], ['e'])
print map(set, [[1]])
> -as well as 'next'.. (any other useful (new) builtin functions
> shedskin doesn't support at the moment?)
done.
> -and while we're passing function references around, it should be
> possible to place these in containers and to pass method references
> around as well
I decided to move this to a future release, because I've seen enough
function passing for now..
> -support for the 'key' argument of 'list.sort' and 'sorted'
done.
> -boost type inference scalability by disallowing parametric
> polymorphism (outside of lib/, as for data polymorphism it's just not
> worth it.)
this is the thing I will look into next. but if I get joris' original
blossoming algorithm to work with a simpler trick, I may also move
this one forward. there's already more than enough new stuff for a new
release.
some other things were improved in the meantime:
- forward referencing of variables and functions
- joris managed to improve basic indexing (without -b, by improving
inlining of __wrap)
- addition of 1-length lists and strings was optimized
- many, many bugfixes.
if I have time, I may look into buffers/memoryviews as suggested on my
blog (thanks!), to avoid copying overhead for extension modules, but I
will probably save this for the next release..
thanks,
mark.
2009/12/20 srepmub <mark....@gmail.com>:
>> -support for itertools (thanks to the work of jeremie)
> jeremie, I'm hoping to see another patch soon.. ^^
^^
To sum up briefly what doesn't work yet for itertools:
- imap
- starmap
- product
- combinations_with_replacement (A 2.7 addition, btw)
The following have been completed since the first patch (and thanks to
Mark's improvements to shedskin):
- chain (accepts an arbitrary number of input iterables)
- tee (accepts an arbitrary number of output iterables)
The following have been added:
- izip (with some limitations: the iterables must be of the same type)
- izip_longest (with some limitations: the iterables must be of the
same type, and there is no way to distinguish None and 0 in the
output)
- permutations
- combinations
> I'd be happy to
> help out if you don't have time to fully complete it, now that most
> other things on this list have been tackled. anyway,
Depends on when you want the module to be complete, but I think
product and combinations_with_replacement will be available very soon
(there is no challenge there).
I haven't thought much about imap and starmap, but I'm expecting some
challenge there... so that's the last I'll work on.
Best regards,
--
Jérémie
Depends on when you want the module to be complete, but I think
product and combinations_with_replacement will be available very soon
(there is no challenge there).
it may be interesting to also add support for 'heapq' before the next
release. it is quite small, and uses several itertools functions..
(see the networkx thread about compiling a graph algorithm that in
turn uses heapq..).
mark.
I'm looking at it this afternoon (unless you've already started to
work on it, of course :p).
--
Jérémie
I'm looking at it this afternoon (unless you've already started to
work on it, of course :p).
I attached a "preview" version, with the following functions :
- heappush
- heappop
- heappushpop
- heapify
- heapreplace
I still have to implement the following :
- merge
- nlargest
- nsmallest
I'm using the same algorithms as CPython.
BTW, concerning itertools, product and combinations_with_replacement
are implemented too.
Best regards,
--
Jérémie
--
Jérémie
--
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.
You're welcome :-)
--
Jérémie
BTW, concerning itertools, product and combinations_with_replacement
are implemented too.
imap, plus :
- a small improvement to izip to (at least) support different
iterables types when there are only two iterables (since this is
already supported by tuples)
- some improvements to "lazyfiy" the combinatoric generators so that
they support infinite iterators as input
I think that's all ;-)
We also have full support for islice, thanks to the special case you
added to cpp.py and the last modifications I've done to it.
> do you agree that starmap
> is too difficult or even impossible to support at the moment?
I'm not sure...
The major challenge with both imap and starmap is to call a function
with parameters that are only known at runtime. I think it is at least
possible to support some hard-coded numbers of parameters ; then we'll
have to find a way to put the parameters on the stack "manually", but
I fear there is no portable way to do this... :s
> I'm making some good progress here as well. with a few minor improvements to
> the type inference engine, I already got the (almost) original matching
> algorithm to compile.. that means it probably won't be necessary to make any
> large changes, and we should be able to release 0.3 in a few weeks.
Great :-)
Oh, BTW, I've noticed a small bug: it looks like shedskin prunes the
functions that are defined but not called, even if they are passed as
parameter to some other function.
Best regards,
--
Jérémie
Attached trivial test case: shedskin generates code that does not compile.
Best regards,
--
Jérémie
I'm not sure...
The major challenge with both imap and starmap is to call a function
with parameters that are only known at runtime. I think it is at least
possible to support some hard-coded numbers of parameters ; then we'll
have to find a way to put the parameters on the stack "manually", but
I fear there is no portable way to do this... :s
Oh, BTW, I've noticed a small bug: it looks like shedskin prunes the
functions that are defined but not called, even if they are passed as
parameter to some other function.
Ok, I understand, I just forgot to call the predicates in the python
stubs. It works now ;-)
Thanks,
--
Jérémie
Well, actually this in not possible, and CPython does not do that either.
The following code in CPython causes an infinite loop, eating all the
available memory :
for i in itertools.combinations(itertools.count(), r = 2):
break
Conclusion: Let's code a Haskell compiler, now ;-)
--
Jérémie
Conclusion: Let's code a Haskell compiler, now ;-)