> http://www.artima.com/weblogs/viewpost.jsp?thread=95863
Thanks
> (It was in Mike's original message.)
I must have missed that. Guido says:
"""
I've yet to see an extension module using SWIG that doesn't make me
think it was a mistake to use SWIG instead of manually written wrappers.
The extr
Christopher Barker wrote:
>
> Eric Firing wrote:
>> Swig:
>> GvR's comments are interesting.
>
> Do you have a pointer to those? I'd love to see them.
http://www.artima.com/weblogs/viewpost.jsp?thread=95863
(It was in Mike's original message.)
Eric
---
Michael Droettboom wrote:
[...]
>
> I think the small amount of support is a valid concern, particularly as
> we move toward Py3k, if no one steps up to the plate to help with the
> migration.
Do you have a sense of how difficult that migration would be?
>
> I appreciate the way it fits so ni
Michael Droettboom wrote:
> Pyrex is "fun to use" and it allows code to be more gradually migrated
> from Python to C. We would need to take care to not add another
> run-time dependency for users.
There are no run-time dependencies with Pyrex -- it generates C code,
which is then compiled.
>
Eric Firing wrote:
> Swig:
> GvR's comments are interesting.
Do you have a pointer to those? I'd love to see them.
My thoughts on SWIG:
It's real strength is that, being automated, it can be used to wrap
large libraries, particularly ones that are constantly evolving
(wxPython). Another one
I don't mind this going on the list with the warning that I was not
trying to start any sort of anti-SWIG movement -- These are just my
first impressions, and at the end of the day I may feel differently. I
think you're *dead on* that personal experience and preferences have a
lot to do with h
Mike,
I hope you don't mind my including the devel list on this; I think it is
a very important topic (although it may be one that ends up coming down
to each individual's personal experience and preferences).
The reasons pycxx worries me are:
0) C++ worries me in general--I know lots of wonder
Hi Eric,
thanks for the warning. I had looked into the issue but never got around
to start working on it.
While you are at it, I would suggest that you split the graphics stuff
out of pylab into a separate
module (pyplot?) to be used for "interactive plotting".
I believe I'm not the only user wh
Mike,
It is a good question.
Right now I am doing some of each. If a function was defined in mlab.py
and it has a replacement in numpy I am issuing a deprecation warning
and passing the arguments to the numpy function. If a function was not
defined in mlab but was imported from numerix, the
Eric Firing wrote:
> Similarly, after dealing with mlab, I would like to simplify pylab.
> Right now, we have a horrible tangle of namespaces in pylab. Cleaning
> this up will potentially break user code; if a numpy function formerly
> could be referenced with three different names and we knock
I have been gradually numpifying mlab.py; I hope this is not a
duplication of effort with someone else. I have not finished yet (and
have made no commits), and it may still take a while--there are a lot of
things to change, and I am trying to do some cleaning up and
rationalization, not just me
Mike,
Thanks for fixing pycxx to remove all those warnings!
I am curious: have you looked at the most recent upstream pycxx? My
impression is that there were supposedly some changes to support python
2.5, and a couple months ago I made a feeble and unsuccessful attempt to
use the updated vers
12 matches
Mail list logo
