Add an optional "driver" parameter to pit_stops()

[alec-kr]

The Problem

The package's pit_stop() function only accepts the year, and also the round # and pit stop # as optional parameters.
There is no way to get the pitstops made by a particular driver during the race.

The Proposed Solution

Therefore, the function can be improved by adding an optional driver parameter. An example function call
will be something like:

// Function call structure
fp.pit_stops(year, round, driver)

// Return the pitstops made by Max Verstappen in the 8th race of the 2022 season 
fp.pit_stops(2022, 8, "max_verstappen")

The data that should be returned by the example function call above can be found here.

NOTE: If the driver name is provided along with year and round, ONLY then should the data for that particular driver during the race will be returned.

Further Information

If incorrect data is passed to the function (incorrect driver name, the round # is left out, etc.), the function MUST be able to throw an error which can easily be understood by the user.

More information on pit stops can be found on the Ergast API website.

[youpong]

What should the fp.pit_stops() signature be?
There are three possible variations, which one would be best?

def pit_stopsA(year: int, race_round: int, driver_id: str=None, stop_number: int = 0, fastest: bool = False):

def pit_stopsB(year: int, race_round: int, stop_number: int = 0, fastest: bool = False, driver_id: str=None):
 
def pit_stopsC(year: int, race_round: int, *, stop_number: int = 0, fastest: bool = False, driver_id: str=None):

I think pit_stopsB or pit_stopsC is good because it is clear, although it breaks backward compatibility.

I have created a repository for consideration.
youpong/F1PyStats-Draft.

[alec-kr]

Hmm. B and C seem like the best possible ways to do this. What exactly do you mean by backward compatibility of this function?

[youpong]

I think pit_stopsB or pit_stopsC is good because it is clear, although it breaks backward compatibility.

Oops!
Correctly, A and C breaks Backward compatibility.

User code:

fp.pit_stop(2023, 24, 1)

Version 0.1.1 receives it as:

year = 2023, round=24, stop_number=1

implementation A receives it as:

year = 2023, round=24, driver_id="1"

implementation C errors requiring keyword args.

I think pit_stopsB or pit_stopsC is good because it is clear, although it breaks backward compatibility.

I think A or C is good because it is clear, although it breaks backward compatibility.

[youpong]

I call it breaking backward compatibility when it requires changes to the user code.

[alec-kr]

Okay I understand. Since it will be a small change in the user code, I think it may be the safest alternative to re-engineering the basis of the function.

If you think we can refactor the function and prevent this, please let me know. We can work on it together.