Referencing #609
Referencing #323
Referencing #410, #413, #414, #418

Is this still needed?

All Python packages should attempt to be properly typed or provide a stubs package that can be used in tandem with their product. See https://peps.python.org/pep-0561/#packaging-type-information ... this helps a LOT with static and runtime type inspection, evaluation, as well as vulnerability fingerprinting and can catch issues well before code using a specific library is committed.

I've attempted to reach out to Kayak through several contacts to see if this is something we could help maintain within this library and not had any response until your comment today.

I am happy to have responded. We will improve its typing.

Having said that and partly read the PEP, I still don't have a clear and good vision how this one file addition solves or helps solve everything but I trust your technical judgement based on the severity of your comments as well as involvement with this repo. Could you elaborate or showcase it with some examples? It would definitely be beneficial to me but since these pull requests are open source, it would be beneficial for someone else inexperienced in this as well.

I asked if it is still needed because I thought that one can do this or type-hint all of the methods. I have looked at the referenced pull requests and they seem to have been merged already. However, from your comment I understand that that is not enough and this is still needed. Am I right about it?

P.S. Please pull the newest code from master so that the CI tests kick in

I am happy to have responded. We will improve its typing.

Having said that and partly read the PEP, I still don't have a clear and good vision how this one file addition solves or helps solve everything but I trust your technical judgement based on the severity of your comments as well as involvement with this repo. Could you elaborate or showcase it with some examples? It would definitely be beneficial to me but since these pull requests are open source, it would be beneficial for someone else inexperienced in this as well.

I asked if it is still needed because I though that one can do this or type-hint all of the methods. I have looked at the referenced pull requests and they seem to have been merged already. However, from your comment I understand that that is not enough and this is still needed. Am I right about it?

P.S. Please pull the newest code from master so that the CI tests kick in

this is not needed for LSP, but it's needed for mypy/pyright.

mypy/pyright only analyze library with py.typed

error: Skipping analyzing "pypika": module is installed, but missing library stubs or py.typed marker  [import-untyped]
note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports

"type-hint all of the methods" is another thing, it won't help this.

that is not enough and this is still needed. Am I right about it?

Yes, setuptools doesn't include it in wheel by default, so we also need update setuptools config to distribut it, what's why setup.py is changed.

Please consider merge this and make a new release.

@trim21 can you confirm this PR would solve mypy conformance? Or did you have to fix additional parts in https://github.com/trim21/pypika-stubs (such as your draft here #815)?

@twheys @mikeengland If this can be confirmed to be a valid fix, could you opportunistically hit the merge button and let this get into the next patch release?

Pypika pollutes every namespace it is imported and used and it is extremely hard to keep such namespaces type-checked with mypy.

from here it only goes downhill:

❯ mypy frappe/types/filter.py
frappe/types/filter.py:18:1: error: Type alias target becomes "str | int | None | datetime | date | Any (from unimported type)" due to an unfollowed import
[no-any-unimported]
    _Val: TypeAlias = str | int | None | DateTime | Criterion
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
frappe/types/filter.py:18:1: note: See https://kotlinisland.github.io/basedmypy/_refs.html#code-no-any-unimported for more info
Found 1 error in 1 file (checked 1 source file)

@trim21 can you confirm this PR would solve mypy conformance? Or did you have to fix additional parts in https://github.com/trim21/pypika-stubs (such as your draft here #815)?

@twheys @mikeengland If this can be confirmed to be a valid fix, could you opportunistically hit the merge button and let this get into the next patch release?

Pypika pollutes every namespace it is imported and used and it is extremely hard to keep such namespaces type-checked with mypy.

from here it only goes downhill:

❯ mypy frappe/types/filter.py
frappe/types/filter.py:18:1: error: Type alias target becomes "str | int | None | datetime | date | Any (from unimported type)" due to an unfollowed import
[no-any-unimported]
    _Val: TypeAlias = str | int | None | DateTime | Criterion
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
frappe/types/filter.py:18:1: note: See https://kotlinisland.github.io/basedmypy/_refs.html#code-no-any-unimported for more info
Found 1 error in 1 file (checked 1 source file)

this PR only make downstream users enable mypy on this package, doesn't make typing right

I believe this benefits a lot of mypy users. I have never used mypy and don't really have a good understanding but, based on the comments, it helps and thus I am merging