Open proofit404 opened 1 year ago
Stories is description first as we define steps before executing the code, it would be great to avoid using plain python for conditional to allow "diagram generation" (like a sequence diagram) from description (Steps and Conditional sub-stories) for example.
We would have almost everything like what xstate does in JS
Syntax
Once again we would change required syntax to work :sweat_smile:Result object is...
a restored context representation from stories version 4.0.
Principles
it
to something likebot
,developer
,admin
etc.if
,else
andmatch
keywords. Access to the state attribute outside of step would be treated as conditional in result representation. It's value still limited to true, false and enum attribute.it
delegate check that step argument is the same as story argument. This pattern would prevent usage of loop inside story definition.stories.typing
would define bunch of generics and protocols for step, steps, state, etc. So it would be possible to annotate story function with__annotations__
future enabled including inner stories.run
method should not care if story is a function, a generator, or a coroutine. This kind of API do not need an executor in the first place.run
method usage should be transparent to the caller code (a Django view for example). But we would explicitly test and document every feature with sync and async variants.repr(purchase)
andrepr(purchase.bind())
would work the same way as it works in stories 4.0.logger.debug
manually in every place. This is boilerplace code we would write inside every Django view. This logger could be an integration layer for pytest, sentry, django logging, ELK, etc. We would document how to use it with most important cases.purchase.use(struct_log_adapter).bind().run()
to stream every step and assignment to ELK using structlog adapter. This adapter return None, so user readable representation is not printed in ipython.2023 Aug 8 update
Typing support for conditional inner stories without
when
andunless
.