Skip to content

naming ? #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MarcWeber opened this issue Apr 10, 2025 · 2 comments
Open

naming ? #3

MarcWeber opened this issue Apr 10, 2025 · 2 comments

Comments

@MarcWeber
Copy link

MarcWeber commented Apr 10, 2025

If you want to be not compatible please choose a new name such as typed_parsy or typed-parsy. Thus

```import typed-parsy````

Then if needed you can import and install both versions in a project without issues.

There is a typed branch in python-parsy/parsy, too.
So its not clear what is meant to be what.

https://stackoverflow.com/questions/7583652/python-module-with-a-dash-or-hyphen-in-its-name
-> looks like hyphens are fine if you use import tools.

This also will allow to have to pip packages etc and avoid chaos.

@spookylukey
Copy link
Member

This repo is experimental, so at the moment there is no plan to create PyPI packages etc.

See https://lukeplant.me.uk/blog/posts/python-type-hints-parsy-case-study/ for background - I will add that to the README

As I have no further plans to develop this, I'm unlikely to work on renames etc. I am open to other people taking the project on if they want, if they have serious plans around it.

@MarcWeber
Copy link
Author

I was looking for a fast combinator library to parse comments from
cupy to get somewhat usable typings. And yeah it worked. The reference you
showed is missing out on @generate thus could be outdated ?

Here is an example about how to solve the seq map thing with Python 3.12
or so which probably was not available 2 years ago.

So I guess giving it a new name, calling it experimental inviting for pull requests might eventually somewhen yield a working typed version. I mean a lot can already be typed and I enjoyed it. Thanks for the work.

Please mind that while TS can map over ARGS Python eventually cannot:
python/typing#1252 (thinks because KWARGS can be passed by name or without language must be changed)
python/typing#1216
[TRICKS] https://github.com/ahmed-mahran/funpy/blob/main/typeargs.py
https://github.com/ahmed-mahran/funpy/blob/main/typeargs.py (TODO review.)

Here is a sketch with simple overloading which shows seq and map and
map_args turning tuple into arguments.

from inspect import BoundArguments
from typing import Generic, TypeVar, Callable, TypeVarTuple, overload, Tuple, Any, ParamSpecArgs, ParamSpec

R = TypeVar('R')
R1 = TypeVar('R1')
R2 = TypeVar('R2')
R3 = TypeVar('R3')

class Parser(Generic[R]):

    def __init__(self, value: R):
        self._value = value
    
    def value(self) -> R:
        return self._value

# Maybe teh overloads can be replaced by [TRICKS] see above
and ParamSpec or such.
@overload
def seq(p1: Parser[R1]) -> Parser[Tuple[R1]]: ...
@overload
def seq(p1: Parser[R1], p2: Parser[R2]) -> Parser[Tuple[R1, R2]]: ...
@overload
def seq(p1: Parser[R1], p2: Parser[R2], p3: Parser[R3]) -> Parser[Tuple[R1, R2, R3]]: ...
def seq(*parsers: Parser[Any]) -> Parser[Tuple[Any, ...]]:
    def combined_value():
        return tuple(p.value() for p in parsers)
    return Parser(combined_value())

P = TypeVarTuple("P")
def map_args(parser: Parser[Tuple[*P]], f: Callable[[*P], R2]) -> Parser[R2]:
    val = parser.value()
    return Parser(f(*val))

# Test
p1 = Parser("abc")
p2 = Parser(2)
s = seq(p1, p2)
map_args(s, lambda a, b: f"{a} {b}")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants