Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Postel's law:

Be conservative in what you do, be liberal in what you accept from others.

"Lazy" code (per The Pragmatic Programmer):

Be strict in what you will accept before you begin, and promise as little as possible in return.

I'm developing a finance (asset pricing, etc.) framework for Python. Question: when designing the API for the framework, what factors should I consider when I assess the tradeoff between being strict and being liberal re: inputs?

Example:

I have the following method that downloads stock prices from Yahoo.

def historical_prices(ticker, start=None, end=None, data='d', convert=True):
# Do stuff

For the date arguments (start & end), I could:

  • Be strict, and only allow a string of ISO format YYYY-mm-dd, or
  • Be liberal and accept datetime objects, strings (of specified formats), etc.
share|improve this question
5  
I'd say be strict and allow only a very specifically formatted string, because converting any string that might happen to represent a date/time in a particular locale is a project in itself, and ambiguous (what day is 1/2/12?) –  Joris Timmermans Jul 30 '12 at 14:11
8  
Why accept strings, and not just use datetime.date objects instead? –  Martijn Pieters Jul 30 '12 at 14:12
    
@MartijnPieters Easier to use strings in REPL ... don't have to create a datetime.date, then call the function. Question still stands even if I switched to datetime.date: do I just allow datetime.date or also allow strings? –  MikeRand Jul 30 '12 at 18:17
add comment

migrated from stackoverflow.com Jul 30 '12 at 14:20

This question came from our site for professional and enthusiast programmers.

3 Answers

up vote 5 down vote accepted

It is going to be easier to accept the strict input, and reject any other forms, because you will have only one case to consider.

It really depends on your customers' requirements. Do they need flexibility of input, i.e. Internationalization, or can they work comfortably with a single format.

share|improve this answer
add comment

Be strict in what you accept. The be liberal in what you accept, and be strict what you return, is based on a world of independent agents, for instance SMTP servers. If a mail server sends you a faulty email, and you can rescue it, that's better than a cryptic error to the sender of the mail.

However, when you're designing an API to be consumed by other programmers, it's different story. They get immediate feedback when they provide wrong input. The other option of guessing what they mean is very dangerous. If you accept 14-12 as december fourtheenth, and 14-10 as october fourteenth, what will your program do with 10-12? Better to be strict, and error with one of them, that way your program will behave in a predictable manner, which is much more important than being able to accept everything.

share|improve this answer
    
what will your program do with 10-12? Don't you mean like 10-13, Mr. markijbema? –  Monty Csquared Jul 30 '12 at 20:19
1  
No, actually not, because 10-12 has two possible interpretations, and 10-13 does not. Therefore I cannot deduce what it will do. If your program is strict though it will have one interpretation, and 10-13 wil either be the thirteenth of october, or crash. Predictable and usable, imho. –  markijbema Jul 31 '12 at 9:01
add comment

I would code the main function with a specific format as the input. If there is a request to add more formats etc then create a function to overload the name that converts the date object etc into your format before calling your main function.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.