-
Notifications
You must be signed in to change notification settings - Fork 474
document settings #722
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
document settings #722
Conversation
Codecov Report
@@ Coverage Diff @@
## master #722 +/- ##
=======================================
Coverage 98.24% 98.24%
=======================================
Files 231 231
Lines 2569 2569
=======================================
Hits 2524 2524
Misses 45 45
Continue to review full report at Codecov.
|
Proposal for deleting |
I think removing them makes sense. |
I will wait until merging this: #779 |
@@ -1,5 +0,0 @@ | |||
Configurations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed as it was not used
@@ -0,0 +1,189 @@ | |||
.. _settings: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a specific section for the settings (extracted from usage.rst
). Multiple error fixes and improvements have been performed.
The instance of :class:`DateDataParser <dateparser.date.DateDataParser>` reduces the number | ||
of applicable languages, until only one or no language is left. It | ||
assumes the previously detected language for all the subsequent dates supplied. | ||
|
||
This class wraps around the core :mod:`dateparser` functionality, and by default | ||
assumes that all of the dates fed to it are in the same language. | ||
|
||
.. autoclass:: dateparser.date.DateDataParser | ||
:members: get_date_data | ||
|
||
.. warning:: It fails to parse *English* dates in the example below, because *Spanish* was detected and stored with the ``ddp`` instance: | ||
|
||
>>> ddp.get_date_data('11 August 2012') | ||
{'date_obj': None, 'period': 'day'} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not true now, so I removed it.
* `SKIP_TOKENS` | ||
* `NORMALIZE` | ||
* `RETURN_TIME_AS_PERIOD` | ||
* `PARSERS` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added all the missing settings and removed the descriptions because it makes this harder to maintain. For up to date descriptions we have the settings section in docs.
@@ -268,7 +268,7 @@ class DateDataParser: | |||
|
|||
:param locales: | |||
A list of locale codes, e.g. ['fr-PF', 'qu-EC', 'af-NA']. | |||
The parser uses locales to translate date string. | |||
The parser uses only these locales to translate date string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarified because of the comment here: #789 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I've been checking the current settings as a previous step to work on this: #630
I've been reordering the settings, reordering the settings in the docs, and checking the currently undocumented settings.The undocumented settings are:* SKIP_TOKENS_PARSER* NORMALIZE* FUZZYI documented theNORMALIZE
setting, however, after some checks, it seems that those settings are not documented because:* It doesn't have any sense or use cases to change them (they were created because of legacy reasons).* Nobody asked for it in issues, etc.From this, I think that they are not useful at all, and it doesn't have any sense to keep them. For example, the default list inSKIP_TOKENS_PARSER
can be set directly in the code, orNORMALIZE=True
can be applied always as it is really specific (it only has sense when the checked source (CLDR json and yamls files) is not normalized, but if it's normalized it doesn't work).My proposal is to remove them in the next major version but I need feedback on this. @GallaecioI documented all the undocumented settings and made some improvements to the documentation structure.