Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Artem Malyshev
    @proofit404
    Here are what I like about this design:
    • it allows to do extended validation for story steps
    • it is IDE friendly
    Ghost
    @ghost~576aa099c2f0db084a1f5559
    Hi, everyone. I have proposed another syntax some time ago: https://github.com/wemake-services/wemake-django-rest/issues/3#issuecomment-433817144
    I have even tried to play around the original code base with no success.
    Artem Malyshev
    @proofit404
    Hi Nikita, It's good to see you! I recall that chats isn't your best option. My apologies.
    Yes, we agreed on low level syntax for stories.
    I'll try to experiment more with class based DSL.
    Serge Matveenko
    @lig

    @proofit404

    it is unclear how to do Skip, Failure and Result behavior without explicit return

    I was thinking about a possibility to use exceptions inside a realization code.
    Skip could be achieved in a more declarative way using if…else inside the story definition.
    While Failure looks like a good fit for raise Failure inside a realization.

    @proofit404

    shall we build something in public as a POC maybe?

    What do you think? An example project which is actually real could serve as a public customer for the stories library and would be a good place to showcase real cases.

    Ghost
    @ghost~576aa099c2f0db084a1f5559
    @lig I disagree with you. if...else case will make the code less declarative. Because they are imperative by their nature. What do I mean? You need some in-place data manipulation in order to define if statement. So we will enforce users to write some-what complex logic in steps definitions. And we may open this method for impure parts including database queries, http calls, etc.
    Artem Malyshev
    @proofit404
    @lig You always can experiment with tutorials project.
    While failure is a good choice for raise exception, skip can not be expressed always in a declarative way. For example, PromoCode sub story: we execute more steps like find_promo_code, check_expiration, cleanup_promocode and return Skip in the middle of substory.
    It still unclear to me, how to deal with Result (raise Result(1)) seems so ugly.
    Artem Malyshev
    @proofit404
    @sobolevn To give you more context about if/else discussion dry-python/stories#76
    Ghost
    @ghost~576aa099c2f0db084a1f5559

    Yeap, I have seen that. But, thanks for sharing anyways!

    Maybe I still don't have enough context, but update_article_post/update_video_post separation seems like an implementation detail to me. I would personally just go with update_post. And inside this regular function there might be a separation between post types, etc.

    What was your motivation?

    Artem Malyshev
    @proofit404
    Sometimes business requirements force us to take different inputs and process them differently.
    For example, based on some flag field in the input.
    Processing article requires different business steps then video uploads. And picture sharing differs from both of them.
    Artem Malyshev
    @proofit404
    The current way to deal with this situation is to write a separate story for each update process. And wrap substories into the main story which will figure out the necessary scenario and pass execution to it.
    Artem Malyshev
    @proofit404
    It is useful to return skip in the middle of the story. For example, if we don't know the necessary conditions.
    But it will be a situation when we define a few business steps in different stories just to check a variable from the context.
    Serge Matveenko
    @lig

    It still unclear to me, how to deal with Result (raise Result(1)) seems so ugly.

    Is Result just a return which is already declared in a stub method?

    @proofit404

    @sobolevn To give you more context about if/else discussion dry-python/stories#76

    with thing looks nice

    It still unclear to me, how to deal with Result (raise Result(1)) seems so ugly.

    Is Result just a return which is already declared in a stub method?

    well, I need to try so called "a la property" approach

    matrixbot
    @matrixbot
    lig this is just a test
    Artem Malyshev
    @proofit404
    Aslo, I plan to add the possibility for `Condition("is_enough_money").do(I.perform_purchaice).otherwise
    (I.show_error)
    To awoid verbosity for booleans check
    Artem Malyshev
    @proofit404
    https://twitter.com/trailblazer_to/status/1059790620498280448
    Trailblazer now supports trading like stories do :)
    Artem Malyshev
    @proofit404
    Hi guys, I post some updates on substories conditionals dry-python/stories#76
    matrixbot
    @matrixbot

    lig > <@gitter_proofit404:matrix.org> Hi guys, I post some updates on substories conditionals dry-python/stories#76

    looks promising. need to try it.

    lig Artem Malyshev (Gitter): I wonder is it possible to use anything instead of I? So, self would also be possible to use
    Artem Malyshev
    @proofit404
    Yes, any name. I described it in the FAQ. https://stories.readthedocs.io/en/latest/faq.html
    Ghost
    @ghost~576aa099c2f0db084a1f5559
    @proofit404 asking about >> syntax. Will it work well with all of these stuff? https://docs.python.org/3/reference/expressions.html#operator-precedence
    And one more question. In languages where we have pattern matching out of the box, we can control how left side is built. What can we do here to limit different user attempts to write something like: when(next(Instance(x, 4, force=True)) >> ... ?
    Artem Malyshev
    @proofit404
    Do you mean other operators?
    Ghost
    @ghost~576aa099c2f0db084a1f5559
    yeap
    Artem Malyshev
    @proofit404
    Other operators are meaningless for dsl. I plan to inlement the right shift only and deny other operators in linter.
    Artem Malyshev
    @proofit404
    Does it make sense?
    Ghost
    @ghost~576aa099c2f0db084a1f5559
    Yes, it does.
    Artem Malyshev
    @proofit404

    And one more question. In languages where we have pattern matching out of the box, we can control how left side is built. What can we do here to limit different user attempts to write something like: when(next(Instance(x, 4, force=True)) >> ... ?

    Sorry, did not see it on my mobile. I think we should not restrict this. The only thing we care is a reference to the value. If user care about code readability, he/she will not write function calls inside when. If the user does not care, what is the point to use dsl in the first place?

    Ghost
    @ghost~576aa099c2f0db084a1f5559
    https://github.com/santinic/pampy
    Artem Malyshev
    @proofit404
    I've done a talk about POC pattern matching implementation done in Python. It looks like this https://github.com/proofit404/proofit404.github.io/blob/master/talks/pattern-matching-in-python/test_patterns.py
    To be honest I just want to give the user an ability to check context variable in one place. I do not plan to implement special syntax for variable unboxing, head/tail comparison, or recursion. If == against value is not enough, user can pass a predicate function.
    Artem Malyshev
    @proofit404
    Or write its own object implementing __eq__ magic method, and do fancy stuff like when(_) or similar.
    Artem Malyshev
    @proofit404
    Hi guys, I wrote documentation for execution rules used in stories https://stories.readthedocs.io/en/latest/execution.html Please, check this out.
    Also, now it's unclear to me how to express everything described there in DSL variant from dry-python/stories#75
    Artem Malyshev
    @proofit404
    Hi guys, I'm planning to try poetry for dependencies management in all dry-python projects. But I'm worries about read the docs issue mentioned here https://twitter.com/playpausenstop/status/1063404164154314757 Anyone has experience in it?
    Ghost
    @ghost~576aa099c2f0db084a1f5559
    @proofit404 yes, I am using poetry for all my project. Feel free to assign me on review.
    Examples: 1. django wemake-services/wemake-django-template#565 2. setup.py replacement https://github.com/wemake-services/wemake-python-styleguide