Dear list members:

I am looking for information on the recommended way to handle mixed return
types from function calls. The following code works as expected in Python:

def return_tests1():
    return 1, 2.0, 3, 4.0
def return_tests2():
    return (1,2), (3,4.0)
def return_tests3():
    return (1,2.0), (3,4), (5,6.0)

if __name__ == '__main__':
    print return_tests1()
    print return_tests2()
    print return_tests3()

Output:
(1, 2.0, 3, 4.0)
((1, 2), (3, 4.0))
((1, 2.0), (3, 4), (5, 6.0))

But the types of the returned variables are altered by Shedskin (0.9.2 with
Python 2.6 under WinXP). In this case, I get the following:

(1.0, 2.0, 3.0, 4.0)
((1, 2), (3, 4.0))
((1, 2.0), (3, 4.0), (5, 6.0))

Note that the first and third lines differ from the Python results.

I realize that the Shedskin documentation sort of mentions this when it
indicates that mixed types in collections are not permitted, but that
tuples of length 2 are allowed to have mixed types. In the event that
multiple return types are needed from a function call, is the recommended
procedure to just pack everything into nested tuples before returning
values? Or is there a better solution available?

And as an aside, I would like to express my thanks to all of the Shedskin
contributors. I just started working with Shedskin this morning, and am
amazed at how simple it has been to get up to speed and get my code
compiled (not to mention see HUGE performance gains). It really has been
extremely easy. So thanks again,

-Mark

Hey Mark,

So it's true a tuple of two can have mixed types, but types are
hierarchical here. A tuple of other tuples has a type of
tuple<tuple<type1, type2>>. In the first line, you have a 4-tuple so
that's going to coerce to one type. And in the third line, you have a
3-tuple of 2-tuples, and the 3-tuple can't have different types for its
internal tuples, to it coerces them too.

Alternatively, you could pass in empty lists that get appended to, or
you can pass in objects that get attributes assigned to in the function.

Farz

hi mark,

And as an aside, I would like to express my thanks to all of the Shedskin

thanks! please let us know when you are allowed to share your program, so
we can have a look if things can be be made to go even faster (either by
changing the program slightly or improving shedskin). I'm also always on
the lookout for interesting programs to add to the examples package.. :-)

thanks again also for reporting the time.localtime/asctime issue you ran
into. please let us know if you run into anything else..

mark.
--
http://www.youtube.com/watch?v=E6LsfnBmdnk

hi mark, farz,

Alternatively, you could pass in empty lists that get appended to, or you

please note that this and other (performance) tricks are described in the
documentation wiki, section performance tips and tricks:

 https://code.google.com/p/shedskin/wiki/docs#Performance_Tips_and_Tricks

another interesting thing that is mentioned here is that attribute access
is (much?) faster than tuple indexing (mytuple.blah versus tuple[0]), since
GCC eats those for lunch.

thirdly, small object allocation is rather slow in compiled code, so
passing in an existing object as farz suggests is a lot faster than
allocating a new object each time. of course if this is not in some
critical path, it's probably nicer to allocate an object each time.

mark.
--
http://www.youtube.com/watch?v=E6LsfnBmdnk

Thanks for fixing the time.localtime/asctime problem, Mark. Seems to be
working just fine now!

-Mark