Function returns object type of Tomorrow when decorated

[jithusunny]

The function with the decoration @threads returns an object of the class Tomorrow even when I return an integer or some other type from the function.

Sample code

from tomorrow import threads

@threads(10)
def test(i):
    return i

for i in range(10):
    print(test(i))

Output

<tomorrow.tomorrow.Tomorrow object at 0x022AA030>
<tomorrow.tomorrow.Tomorrow object at 0x022AA030>
<tomorrow.tomorrow.Tomorrow object at 0x022AA030>
<tomorrow.tomorrow.Tomorrow object at 0x0228FAD0>
<tomorrow.tomorrow.Tomorrow object at 0x01F44B90>
<tomorrow.tomorrow.Tomorrow object at 0x022AA030>
<tomorrow.tomorrow.Tomorrow object at 0x0228FAD0>
<tomorrow.tomorrow.Tomorrow object at 0x01F44B90>
<tomorrow.tomorrow.Tomorrow object at 0x022AA030>
<tomorrow.tomorrow.Tomorrow object at 0x0228FAD0>

[madisonmay]

Any chance you're on Python3? Running the same code snippet on my system produces the expected result.

0
1
2
3
4
5
6
7
8
9

[jithusunny]

Yes.
Sorry, I 'assumed' I can use the library with Python 3.x!

Still, any idea how to fix this?
I tried _wait() call method, but it is a blocking execution then.

Thanks,

[madisonmay]

No worries! Unfortunately, the library will simply not work on Python 3.x. I take advantage of some Python 2.7 specific "features" -- namely the fact that old-style python classes have calls to dunder methods (__init__, for example) routed through the __getattr__ method. I would recommend working with concurrent.futures directly in general -- it's an excellent library and quite a bit more transparent. Tomorrow is mainly a thought experiment to see how low I could make the barrier to switching to a threaded model.