Recommended way to handle mixed type returns from functions

[Mark]

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

[Fahrzin Hemmati]

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

> --
> You received this message because you are subscribed to the Google
> Groups "shedskin-discuss" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/shedskin-discuss/-/59VhhTeZpGIJ.
> 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.

[Mark Dufour]

hi mark,

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,

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

[Mark Dufour]

hi mark, farz,

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.

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

[Mark]

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

-Mark