[SciPy-dev] Problem solved ---- Sorry!

[eric]

> On Wed, 30 Jan 2002, eric wrote:
>
> > code = """
> >        return_val = Py::new_reference_to(Py::Int(a+b+c+d));
> >        """
> > weave.inline(code,['a','b','c','d'])
> > weave.inline(code,['b','c','d','e'])
> >
> > In the second version, are the argument names substituted positionally
or
> > by name?  If we go with positional, then the idea of the C/C++ code
being
> > a continuation of the python code is "broken", and this becomes more of
a
> > function call.
>
> I hope you're not considering 'going positional'. It would make weave's
use
> very unnatural and bizarre, IMHO. The way it currently works seems
perfectly
> natural and logical to me (hopefully it's not that confusing to others
once
> they realize how to use it once).

inline was intended not to be positional and ext_tools provides function
like behavior.  But Andreas getting confused about inline's behavior, and
the fact that I have thought about positional arguments before, does mean
that there isn't a cut-and-dried "obvious" behavior. However, I'm fairly
comfortable with the current behavior, and without some very good reasons to
change it, it'll stay that way.

>
> > Eventually, I'd like to remove the need to specify the argument list.
> > This would require some C/C++ parsing of the code string to find the
> > necessary arguments.
>
> Please follow this route *only* if you can be positive that it's really
solid.
> It sounds tricky to make it really robust and a fair bit of work, and the
> 'inconvenience' it addresses seems reasonably minor to me.

I think its possible to make it solid, but it would be a big project and the
benefit versus level of effort is really low.  So, like you, I see it as
pretty far down the list of desired features.  I tend to go for the low
hanging fruit while it is still there...

> I also kind of like
> the fact that the argumnent list gives me a known interface between the
two
> layers of code, so if I care to define an 'i' counter in C even if I had
one
> in Python, it's not a problem.

Well, that kinda breaks the notion of the C code as a continuation of the
Python code where all variables are shared between the two.  Your right, it
can be useful to specify what crosses the C/Python boundary, but it also
isn't also isn't so hard to rename variables that clash.  But see the
previous comment as to how likely this is to change in the near future.

> I don't know, maybe others feel differently but
> from the possible areas for weave to improve (and where your time and
effort
> can go), to me this one doesn't really feel that critical.

Agreed.

eric