Hi,
thanks for reaching out! Filterung jobs by regex sounds like a reasonable use case for me, so I'm open to a contribution 👍
Your proposed interface does work, however I'm not sure if it the most natural implementation. Having a new parameter use_regex modify how the name parameter is interpreted doesn't feel straight forward to me. Plus the _by_name part would then no longer be really true 😅

What do you instead think of the following:

• add an optional paremeter pattern to jobs so that jobs() still returns all jobs but jobs(pattern) filters based on the regex
• refactor get_jobs_by_name by making it call jobs(f"^{name}$")

The filtered search would then be available through jobs rather than get_jobs_by_name.

Good day @Bibo-Joshi !
Yeah, looking at the code of get_jobs_by_name in the actual implementation, and adding the parameter that I added, I actually thought that it could generate a little bit of (justified) confusion, due to the ambigue role of name.
Let me see how can I implement your suggestion, and I'll get back to you.
In the meanwhile, have a good day!

@Bibo-Joshi This is my proposition:

def jobs(self, name: str) -> Tuple["Job[CCT]", ...]:
    """Returns a tuple of all *scheduled* jobs that are currently in the :class:`JobQueue`,
    matching the :obj:`name` provided.

    Returns:
        Tuple[:class:`Job`]: Tuple of all *scheduled* jobs.
    """
    pattern = compile(str(name))
    return tuple(Job.from_aps_job(job) for job in self.scheduler.get_jobs() if pattern.search(job.name))

def get_jobs_by_name(self, name: str) -> Tuple["Job[CCT]", ...]:
    """Returns a tuple of all *pending/scheduled* jobs with the given name that are currently
    in the :class:`JobQueue`.
    Please note that the parameter :obj:`name` accepts regular expressions.

    Returns:
        Tuple[:class:`Job`]: Tuple of all *pending* or *scheduled* jobs matching the name.
    """
    return tuple(job for job in self.jobs(name=f"^{name}$"))

The parameter name added in the jobs method can't be optional, otherwise all jobs would be returned.
Being said so, with the suggestion you proposed, I managed to filter the jobs providing a regular expression in the name parameter of the _get_jobs_by_name", keeping the logic as it was before thanks to the anchors ^ and $ inserted respectively in the name parameter of the _jobs_method.
Tested a little bit around, and as long as the user is not providing any strange regular expression, the result would just be a no-match, as it was before.
Let me know if I can proceed with this new feature integration 🙂

Hi, thanks for getting back. Three remarks that I see on first glance:

1. The new argument of jobs should be named pattern as a regex pattern is what's expected. Moreover it could also accept re.Pattern objects in addition to strings.
2. The new argument must be optional, otherwise it would be breaking backward compatibility. If no pattern is passed, jobs() should just return all jubs as it's currently done.
3. To ensure that regex syntax within the name argument of get_jobs_by_name doesn't break the logic, you can use re.escape.

I suggest that you draft a PR with your edits so that we can do a proper review on the PR :) Please be sure to follow our contribution guide, especially the checklist

FYI, I went ahead and openend #4613