Skip to content
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

feat: python class for available filters #1322

Open
Dr-Blank opened this issue Dec 26, 2023 · 3 comments
Open

feat: python class for available filters #1322

Dr-Blank opened this issue Dec 26, 2023 · 3 comments

Comments

@Dr-Blank
Copy link
Contributor

What is your feature request?

search(title=None, libtype=None, **kwargs)
and other methods which rely on kwargs for search would be able to accept this filter object
will add editor support for filters

Are there any workarounds?

currently one needs to refer documentation for this and pass in the filters as kwargs, which do not give proper developer support

Code Snippets

No response

Additional Context

somehting like this

filter = Filter().genre("foo").year(le=2020)
# or 
filter = Filter(genre="foo", year=2020)

lib.search(filter=filter)
@Dr-Blank
Copy link
Contributor Author

Where should I put classes and functions related to this PR?

utils.py is growing and there is no discussion on #1291 yet

proof of concept here

@JonnyWong16
Copy link
Collaborator

I don't see the point of doing this. It overcomplicates things.

@Dr-Blank
Copy link
Contributor Author

I don't see the point of doing this. It overcomplicates things.

I understand your concern about potential overcomplication, but I would like to reiterate the benefits and the rationale behind this proposed feature as I feel i might have done a poor job in the first place.

  1. Compatibility: One of the key advantages of the proposed changes is that they do not break compatibility. Users who are comfortable with the existing method of using strings and dictionaries for filtering can continue doing so without any disruption. The introduction of Python mappings simply provides an additional, more convenient option for those who prefer a more programmatic approach.
  2. Project Intention and Pythonic Design: The core purpose of our project is to provide a Python interface to the Plex API. By introducing Python mappings for generating filters, we are aligning with the Pythonic principles and making the API more intuitive for Python developers. This enhancement is designed to facilitate a smoother and more natural interaction with the Plex API, which is consistent with the goals of the project.
  3. Editor Support and Reduced Error-Prone Usage: The introduction of Python mappings not only enhances the development experience but also significantly reduces the chances of errors. Developers can benefit from improved editor support, including autocompletion, which streamlines the coding process and minimizes the need for constant reference to documentation. This feature can be particularly helpful for those who are new to the project or have limited familiarity with the available attributes.
  4. Parallels with SQLAlchemy: SQLAlchemy adopts a Pythonic approach by offering a Python interface instead of relying on raw strings for queries. This design choice has been well-received in the community and has contributed to the popularity and usability of the library.

here is how it would look if implemented

from plexapi.audio import Album, Artist, Track
from plexapi.utils import Filter

# Using Python mappings for filter generation
lib.search(filter=Filter(
    Album.genre == "Rock",
    Track.rating > 3,
    Artist.collection != 'Christmas'
))

I appreciate your time and consideration on this matter, and I am open to further discussion or modifications to address any concerns you may have.

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

No branches or pull requests

2 participants