rustedpy / maybe Goto Github PK

I'd like to add ok_or and ok_or_else methods, following Rust's behavior for them:

• Rust's ok_or
• Rust's ok_or_else

I realize that this means that this library would then require the rustedpy result library as a dependency. Although both are quite small, I'd be happy to make result an "extras", if you want to allow users to avoid the extra dependency, if they're not using it.

My motivation here is that I have a function that returns a Maybe, but there are cases where I want to convert it to a Result. In particular, this would allow me to make use of it within a result.do call.

For example, if function f returns a Maybe, I can make use of a call to f in a result.do by using ok_or (or ok_or_else), such as in this dummy scenario:

result.do(
   Ok(x + y)
   for x in f(...).ok_or("error message")
   for y in g(x, ...)
)

The github actions in ci.yml are a bit outdated. I propose bumping to their latest versions, which will also allow some simplification to dependency caching since the setup-python action now leverages the cache action, allowing for less boilerplate in the workflow file.

I also propose adding a .github/dependabot.yml file to check for github action updates on a monthly basis.

Hi there @francium! I couldn't find your contact information, so I hope it's okay I write here.

Love your work on Result and Maybe! When working in Python, I've sorely missed .into_iter(), .map() etc.

I've been at work on a package to solve that, FunctionalPy.

It's at an early alpha stage, and I'm strongly considering:

• Supporting Result/Maybe
• Renaming the package to Iter

I think the rustedpy org might be a good home for a package like that, and I'd gladly volunteer as maintainer. Any thoughts? :-)

We may need to think about if the semantics differ in the context of a Maybe vs a Result

@francium, I know you have an old PR for this (#7), but thought I would make a corresponding issue because I am attempting to create a new PR (per your suggestion in #7), but I am finding the following anomaly with lazydocs: it doesn't deal with REPL syntax properly.

In particular, here is a problematic part of a docstring from the is_some function (and similarly for is_nothing):

    Usage:
    >>> r: Maybe[int, str] = get_a_maybe()
    >>> if is_some(r):
    >>>     r   # r is of type Some[int]
    >>> elif is_nothing(r):
    >>>     r   # r is of type Nothing[str]

Unfortunately, the generated HTML renders as follows:

Usage: r: Maybe[int, str] = get_a_maybe() if is_some(r): r # r is of type Some[int] elif is_nothing(r): r # r is of type Nothing[str]

This sort of makes sense in terms of pure translation of markdown to HTML because there are no intervening blank lines, so all of the lines are interpreted to be part of the same "paragraph," so each intervening newline is replaced with a single blank, and we end up with all of the "code" joined onto a single line.

Sadly, as far as I can tell, there is no way to completely correct this to allow correct rendering of REPL prompts, which is also sad because that eliminates the possibility of including doctest tests and having them rendered correctly in the generated docs.

For starters, I added a blank line after "Usage:" and surrounded the REPL lines in a plain code fence, like so:

    Usage:

    ```plain
    >>> r: Maybe[int, str] = get_a_maybe()
    >>> if is_some(r):
    >>>     r   # r is of type Some[int]
    >>> elif is_nothing(r):
    >>>     r   # r is of type Nothing[str]
    ```

This produced an even worse rendering:

Usage:

``` r: Maybe[int, str] = get_a_maybe()``` ``` if is_some(r):```
```     r   # r is of type Some[int]``` ``` elif is_nothing(r):```
```     r   # r is of type Nothing[str]``` ```



---

<a href="https://github.com/rustedpy/maybe/blob/main/src/maybe/maybe.py#L299"><img align="right" style="float:right;" src="https://img.shields.io/badge/-source-cccccc?style=flat-square"></a>

## <kbd>function</kbd> `is_nothing`

```python
is_nothing(maybe: 'Maybe[T]') → TypeGuard[Nothing]

Of course, I realize that the REPL syntax should actually be corrected as follows (notice, the ... in place of some of the >>>), if it is to be a true REPL representation:

    Usage:

    ```plain
    >>> r: Maybe[int, str] = get_a_maybe()
    >>> if is_some(r):
    ...     r   # r is of type Some[int]
    ... elif is_nothing(r):
    ...     r   # r is of type Nothing[str]
    ```

Unfortunately, that does not render any better, nor did I really expect it to, since ... vs. >>> is not the source of the rendering problem.

The "fix" is to simply remove the REPL prompts, and make it a regular code fence, like so:

    Usage:

    ```python
    r: Maybe[int, str] = get_a_maybe()
    if is_some(r):
        r   # r is of type Some[int]
    elif is_nothing(r):
        r   # r is of type Nothing[str]
    ```

This renders like so:

Usage:

r: Maybe[int, str] = get_a_maybe()
if is_some(r):
    r   # r is of type Some[int]
elif is_nothing(r):
    r   # r is of type Nothing[str]

Are you okay with making this type of adjustment to the docstrings for both is_some and is_nothing?

Hello,

I would like to know if there is a way to create Some or Nothing based on a value. Specifically, if the value is None, it should create Nothing, and if the value is present, it should be encapsulated within Some.

I saw a great example of this in one of the libraries that was put as an alternative to your repositories. This implementation is the one I am referring.

If this functionality does not currently exist, I am willing to implement it if we can agree on the approach.

My question concerns the initial decision to split result and maybe into two separate repositories/libraries. From my understanding, both encapsulate the concept of railway-oriented programming. I believe it would be much simpler if they were merged into the result library, as I currently need both in my project.

I'm highlighting this issue because I encountered problems running pytest on this library. Specifically, rustedpy-maybe is defined as maybe under the src directory. As a result, pip install -e . doesn't work correctly since it tries to find rustedpy_maybe under src, fails to locate it, and causes conflicts. I have already merged the two projects locally, but this isn't backwards compatible because instead of using from result import *, you now have to use either from result.result or from result.maybe. If we agree to merge these two projects, we need to decide on the approach. We could maintain from result import * and add from result.maybe separately, but I believe it's better to import explicitly.

What are your thoughts on this? I've already created a function maybe(v: T | None) -> Maybe[T] (issue #4) and two decorators as_maybe and as_async_maybe (issue #1). Everything is tested and type-hinted, so if we decide to proceed, I can submit a comprehensive pull request to the result library containing all these changes.

Alternatively, if you prefer to first implement these changes in the current library before considering a merge into result, we need to address the naming issue. One solution could be to rename src.maybe to src.rustedpy_maybe, or perhaps you have another workaround in mind?

There's some ongoing work, don't want to change until that's completed to avoid disrupting things.

Hello, thank you for the two excellent packages. The README reads, "Not yet available on PyPI. PyPI package coming soon," but the last commit was four months ago. Please release maybe on PyPI when are you able for versioning reasons.