Not sure of this failure. If the given list of languages is empty in this case then it should use the defaults.

I'm thinking on the case where this is combined with a language detection model. For some cases, the prediction could fail and not return any language, but still, dateparser must try its best.

I do see your point, and I agree. The question is if this is what's expected: to restrict to the given locales (or languages) or to use those as a starting point but try the other locales anyways.
If the second is true, then removing this check should be the right choice.

I can talk about the use case I have in mind: using a page language detector to provide hints to have better date parsing. In this case, what you have is just hints:

• In some case, you don't get any language from the language detector. Still, you want dateparser to try its best.
• In some cases, the list won't be complete. You don't want to remove locales just because the language detector didn't detect them.

So from my point of view, this list should be just hints: they can change the order of the default locales, but never restrict them.

Hi @ivanprado, the languages and locales parameters have been used historically for restricting the used languages. This is sometimes really important and helps to improve the performance, so I think we can't change them to work as you mentioned.

However, what you say sounds like adding something new like a exclude_languages parameter, so you could do something like this:

date = dateparser.parse("<date string>", languages=['ru', 'tr', 'es'])
if not date:
    date = dateparser.parse("<date string>", exclude_languages=['ru', 'tr', 'es'])

What do you think? Could this work for you?

Also, on the argument of not raising an exception because the calling code may provide an empty list, the calling code should also be able not to set that setting when that happens. I fail to see the point of removing the exception.

@noviluni I see your point. It was not clear to me that locales and languages were used as contraints to improve performance. The documentation (https://github.com/scrapinghub/dateparser/blob/master/dateparser/__init__.py#L23-L31) is ambiguous, and my first thought was that they would be used as "hints" . I think it would be great to update the documentation to make it clear that they restrict the languages used.

Given that languages and locales are for restricting I agree with you than then maybe is not the best place for the use case I'm proposing. What I'm proposing is to be able to propose "hints" for the locales/languages. I don't think exclude_languages should be way.

What do you think about a new parameter language_hints? It would be used just to alter the languages/locales priorities.

we should probably deprecate this instead of just removing it, but maybe we can do it as we are going to release a new version with multiple breaking changes. cc: @Gallaecio

I'm not sure if it's better to keep the False by default or to change to True. Any strong opinion?

I think False is right as a default because that way you'd get the added benefit of trying your most likely language first. If you give a list of locales I'd assume you want the date to be extracted correctly regardless of which of your locales is the right one. Also, I would argue that expecting it to be as efficient as possible by default is better if you allow the customization.