TM1py 2.0 - Feature Requests and Breaking Changes

[MariusWirtz]

This summer we should release the 2.0 version of TM1py.
I would like to start a discussion about what features we should include in the release and whether we should introduce any changes.
Please comment on this thread if you have any thoughts or ideas for features to include!

Perhaps the upcoming 2.0 release is a good opportunity to introduce (intentional) breaking changes for the first time.
Not only because it's a major release, but also because TM1 12 should be released around the same time and comes with its own breaking changes (AFAIK).
I think we have accrued a bit of "technical debt" over the years that is hard to get rid of due to our efforts to stay backward compatible. Like some of the things I have in mind is just naming. Like in some functions arguments are called name_process instead of process_name. Talking about names, to be compliant with the general python package naming conventions, the TM1py package should be called tm1py. I could go on, but I'm not sure if it bothers other people as much as myself?
Over the next weeks, we can discuss those points on a granular level in this thread.
Please comment if you have ideas on how to tidy up TM1py. This major release might be the last chance we get.

Other breaking changes we could do are around default values for arguments.
I would like to change a couple of those too. For instance, I think on the execute_set_mdx all defaults should be None except for member_properties
What are your thoughts on default arguments? Any proposals?

[rclapp]

I agree. One thing I have had my eye on for a while is abstracting the asyc code into its own module. When building serverless a application timeouts are a concern. Moving the async code to its own module would allow builders to write functions (like on aws lambda ) that executes requests, and another that checks the status of the requests.

[MariusWirtz]

I think I understand. I think I would need to see something in code to fully grasp the idea though.
Either way, if this helps to make TM1py more useful I'm happy to help building the feature.

[MariusWirtz]

I would suggest removing all the MDXUtils functions in the Utils module that have been deprecated for a while now.

[MariusWirtz]

This release could be a good opportunity to continue @scrambldchannel work (#301) and rewrite the tests to use pytest and fixtures.
Ideally, this leads to a leaner and cleaner test suite that further encourages contributors to write tests

[cubewise-tryan]

I wouldn't recommend breaking changes because of naming conventions or other cosmetic things. There should be a significant improvement to the developer experience to justify the pain that will be experienced.

[MariusWirtz]

I guess you are right. In the end, code beautification doesn't justify the extra work for people using TM1py in production.
We would need a better reason to make breaking changes.

[rclapp]

Understood. The issue is that serverless functions, such as aws lambda, have a 15min time out. So any long running operations built on TM1py become a challenge. To fix this I want expose the underlying async framework. That way there are easy to use methods like async_get_status and async_get_reaponse. The current implantation is focused on ibm cloud, but makes custom use of the async framework hard.

…

Sent from my mobile device On Apr 1, 2022 3:45 AM, Marius Wirtz ***@***.***> wrote: I think I understand. I think I would need to see something in code to fully grasp the idea though. Either way, if this helps to make TM1py more useful I'm happy to help building the feature. - Reply to this email directly, view it on GitHub<#706 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEK7GZT26FXOVWTCNK5LA43VC3HTZANCNFSM5SB3YDRQ>. You are receiving this because you commented.Message ID: ***@***.***>

[MariusWirtz]

I see. That makes total sense.