Thanks @llchan and @mrsaints – I need some time to digest this – but at least I know now that the external API contract needs a bit more work.
I’m leaning towards this at the moment and removing the iscoroutinefunction check.
The repo is now public:
There is plenty of sample code in the “tests” directory.
Feel free to submit any comments here.
Regarding PRs – I don’t have much time to review PRs at the moment but feel free to submit them if you don’t mind waiting – could be more than a month before I can get around to reviewing your PR. I would suggest submitting an issue first and only submitting a PR after some discussion in the issue.
Next things on my todo list
- promises / parallel activity support
- some kind of stress testing to verify that I got the async code correct and that I’m cleaning up async tasks properly after workflow/activity execution
- some type of recovery code for when workers get disconnected from the Temporal service
- technical debt: use the official betterproto package rather than a fork
- publish to pypi
Let me know if you have any thoughts on the proposed parallel activities API
5 Likes
Do we have a preference on whether discussion happens here, in GH issues, or in a higher-density chat medium like slack/gitter/whatnot? I took a look at the async stuff and it appears to me to be non-async, but maybe I’m misreading something. Specifically the activity loop, it seems like it pulls requests off the queue and processes them one at a time?
I would recommend coming up with an API proposal for Python the same way it was done for PHP. The discussion can happen in the PR comments.
Okay, sounds good. I can start a async python one, with the disclaimer that I am relatively new to cadence/temporal.
General question since I don’t know who works at Temporal and who doesnt: is this python SDK owned by Temporal? If so, can we move it to the temporalio org sooner rather than later? IMHO it’s fine to have pre-release stuff in there given that it already has a “this is experimental” disclaimer.
At the moment each worker fetches and processes one activity at a time.
Of course you can run multiple workers.
I don’t work for Temporal but it’s MIT licensed which puts very few restrictions on how the code can be used. PRs are welcome.
Currently, I’m implementing DataConverter and possibly changing everything to run in the main event loop rather than an event loop per thread. So after this the Python library won’t be launching any threads.
It’s going to be sideway motions for a few weeks - while I refactor this and resolve some other technical debt.
First time poster here after searching and googling around the topic of workflow.
I am using Django for my work and was wondering if temporalio + firdaus’ python SDK will work when the workflow elements live in the database, rather than purely in the code.
Meaning to say, states, transitions, authorizations etc are persisted in the database. If I were to change those, there’s no need for me to redeploy the applications.
Hence I was looking at a library like django-river
I like what temporalio promises. Fault-oblivious stateful workflow as stated in the overview of its docs at https://docs.temporal.io/docs/workflows.
I am not entirely sure, but was wondering if somehow I can have best of both worlds?
- on the fly changes for transitions, states, authorizations without redeploying
- fault-oblivious stateful workflow
By combining with the django-river and the python SDK? Or I need to choose temporalio and then adapt around it?
Conceptually Python SDK is similar to all other SDKs. So anything you can do in any other language should be possible in Python.
As workflows are code it is pretty straightforward to implement an interpreter for your DSL (Domain Specific Language). There are many use cases that use this approach to support workflows that are configured through XML/Yaml/JSON/DB.
I’m working on a Java DSL sample. Here is the Go one.
1 Like
Hey @firdaus, thanks so much for putting this out, this is awesome. My team is investigating implementing this SDK, but I’m interested in a little clarification on your intent to support or not support it now that it is released.
I see your Note on the repo “NOTE: I’m no longer working on this SDK. I will be refocusing my efforts on downstream tools.” - and that is scary to my manager.
However I also see your comment here: “Regarding PRs – I don’t have much time to review PRs at the moment but feel free to submit them if you don’t mind waiting – could be more than a month before I can get around to reviewing your PR. I would suggest submitting an issue first and only submitting a PR after some discussion in the issue.”.
My assumption is that you have implemented the python SDK for your own use so that you can build some tooling on top of it for your own work/projects and that you are kindly releasing it FOSS as well for us. And thanks again for that. But as far as support and expected life of the SDK - can we expect that this SDK will be alive for awhile and receive some kind of active development, or no?
Thanks!
1 Like
Just +1’ing @irvenae. The temporal-python-sdk looks to be nicely implemented and tested, great work! Is there any chance it could be moved to the same official-but-alpha status as the typescript stuff @ryland? Just going through the project it seems like a lot of the remaining work is infrastructure-ish stuff that might be more suited to a company than OSS contributors; stuff like CI, repackaging to extend dependency version range, running a full multilanguage test suite, etc.
5 Likes
Also would like to ask about if there are any updates on an official python SDK?
Nothing official yet. Will make sure to update this post as soon as there is something to publicly share.
Was told that it’s ok to share that Python is the next SDK we will be working on 
3 Likes
@tihomir Thank You! Any updates and even small progress on python SDK would be awesome and keep us motivated. Thanks a lot, Temporal team.
Here is the initial proposal that SDK team is discussing currently. Note that the link may be replaced at some point as things move around, but just wanted to share.
After lots of discussion on that PR and in roundtables and such, a new one has been opened for more feedback: Python SDK - Phase 1 by cretz · Pull Request #50 · temporalio/proposals · GitHub.
1 Like