Is there a way to wrap the final return statement? Instead of:
return resultobj;
do:
return CheckIfSingleTuple(resultobj);
That would also help us in the case where it's a single value, that way we
wouldn't have to worry about whether or not we have only a single value in a
tuple until it's time to actually return the value.
> -----Original Message-----
> From: Marshall White [mailto:cscidork@yahoo.com]
> Sent: Thursday, February 27, 2003 4:54 PM
> To: Dale Hirt; kfogel@collab.net
> Cc: dev@subversion.tigris.org
> Subject: RE: inconsistency in Python SWIG return parameters
>
>
> (Speculation) My guess is that the SWIG interface functions
> must return SOME kind of Python
> object. Setting "Py_None" right off the bat makes it the
> default in case of no other return
> values. I would also guess that returning NULL would be
> bad... The code seems to do that on
> error conditions.
>
>
> I believe this whole problem would be relatively simple to
> work around IF a single-valued PyTuple
> is okay. (Isn't that an oxymoron?)
> http://dictionary.reference.com/search?q=tuple
>
> I am not brave, and I haven't tried it, but you could do
> something like the code below. The only
> difference between it and "t_output_helper" is the middle
> "else if" clause.
>
> It gives the effect of ignoring the "default" Py_None, and
> sticks ALL subsequent objects into the
> tuple regardless of what they are. Just remember that if it
> is only called ONCE, it will give a
> "single-valued PyTuple."
>
> Please note that it would be extremely wise to see how Python
> would react before trying it. That
> is go see if the Python source code would "eat your hard drive."
>
> The "woman" is telling me that it is HER turn to use the
> computer now. Good night gentleman.
>
>
> static PyObject* NEW_t_output_helper(PyObject* target, PyObject* o) {
> PyObject* o2;
> PyObject* o3;
>
> if (!target) {
> target = o;
> } else if (target == Py_None) {
> Py_DECREF(Py_None);
> target = PyTuple_New(1);
> PyTuple_SetItem(target, 0, o);
> } else {
> if (!PyTuple_Check(target)) {
> o2 = target;
> target = PyTuple_New(1);
> PyTuple_SetItem(target, 0, o2);
> }
> o3 = PyTuple_New(1);
> PyTuple_SetItem(o3, 0, o);
>
> o2 = target;
> target = PySequence_Concat(o2, o3);
> Py_DECREF(o2);
> Py_DECREF(o3);
> }
> return target;
> }
>
>
>
> --- Dale Hirt <dale@sbcltd.com> wrote:
> > Well, now I just need to get up to speed on Python. So
> far, my big question
> > is, why does resultobj get set to Py_None right away.
> That seems to me to
> > be pretty silly. It should be set to NULL, otherwise, if
> we use a newer
> > version, then it will return 3 args, instead of the 2 that
> we desire. Hmmm,
> > let me think on that part, too.
> >
> >
> > > -----Original Message-----
> > > From: Marshall White [mailto:cscidork@yahoo.com]
> > > Sent: Thursday, February 27, 2003 3:55 PM
> > > To: Dale Hirt; kfogel@collab.net
> > > Cc: dev@subversion.tigris.org
> > > Subject: RE: inconsistency in Python SWIG return parameters
> > >
> > >
> > >
> > > --- Dale Hirt <dale@sbcltd.com> wrote:
> > > > > -----Original Message-----
> > > > > From: Marshall White [mailto:cscidork@yahoo.com]
> > > > [snip]
> > > > >
> > > > > It looks to me like one possible culprit, this funky
> > > > > "t_output_helper", is generated by SWIG.
> > > > >
> > > >
> > > > You're reading my thoughts on this one. So far, if
> we're to change
> > > > anything, this is where I would start. However, then it
> > > becomes a matter of
> > > > how do we understand that there is indeed more than one
> > > return value, or
> > > > that a None value is permissible. You were right in that
> > > t_output_helper is
> > > > lazy, but making it work for it's dinner is going to be
> hard without
> > > > breaking a lot of code. Boy, talk about a nice complex issue.
> > >
> > > Well it looks like that "generated" was not the right word.
> > > It is hard coded in a file called "fragments.i"
> > >
> > > Greg Stein just posted an email with a wonderful suggestion.
> > > Perhaps a function similar to "t_output_helper" could be
> > > written that "does the right thing."
> > > In the "*.i" files this new function could be specified
> > > instead of "t_output_helper".
> > >
> > >
> > > >
> > > > > From reading I see that Dale Hirt is looking into this.
> > > > > I wish him the best of luck. Perhaps there are command line
> > > > > options for SWIG that might change
> > > > > the default behavior of this function. A very quick glance
> > > > > didn't show anything obvious though.
> > > > >
> > > > > I don't want to *duplicate* his effort, but I will look into
> > > > > this some myself. Maybe two sets of
> > > > > eyes might be better than one.
> > > > >
> > > > Any and all help is always appreciated. Like I said
> > > before, I'm a relative
> > > > newcomer to Python, Python extensions, and SWIG, so having
> > > you look also
> > > > should help a lot.
> > >
> > > I am a newcomer as well. I have been looking at Python for
> > > about a month now.
> > >
> > > >
> > > > >
> > > > > Marshall
> > > >
> > > > Thanks,
> > > >
> > > > Dale
> > >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 28 02:00:57 2003