functions_date.py

[ufoptg]

Summary by Sourcery

Enhance the UserDateEstimator class by adding a check for existing tg_id values in the data and improving the time_format method to provide more detailed output. Add new data entries to the dataset.

Enhancements:

• Add a check in the func method to return the exact value if the tg_id exists in the data.
• Improve the time_format method to return both the formatted date and the age in years, months, and days.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request updates the UserDateEstimator class in the functions_date.py file. The changes improve the functionality and efficiency of the class, add new data entries, and refactor some methods for better readability and flexibility.

File-Level Changes

Change	Details	Files
Added new data entries to the data dictionary	Added two new key-value pairs to the data dictionary	RyuzakiLib/functions_date.py
Refactored the UserDateEstimator class initialization	Changed the __init__ method to use the order parameter Simplified the return statement in _unpack_data method	RyuzakiLib/functions_date.py
Updated the func method to check for existing data	Added a check to return exact value if the tg_id exists in the data dictionary	RyuzakiLib/functions_date.py
Refactored the time_format method	Removed the fmt parameter and hardcoded the date format Changed the return value to a tuple of formatted date and age Updated the formatting of the age string	RyuzakiLib/functions_date.py

---

Tips

• Trigger a new Sourcery review by commenting @sourcery-ai review on the pull request.
• Continue your discussion with Sourcery by replying directly to review comments.
• You can change your review settings at any time by accessing your dashboard:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[sourcery-ai]

Hey @ufoptg - I've reviewed your changes and found some issues that need to be addressed.

Blocking issues:

• Potential hard-coded secret found in data dictionary. (link)
• Potential hard-coded secret found in data dictionary. (link)

Overall Comments:

• Consider simplifying the polynomial fitting to a linear regression unless there's a specific need for higher-order polynomials. If keeping the current approach, please provide justification for the chosen polynomial order.

Here's what I looked at during the review

• 🟡 General issues: 1 issue found
• 🔴 Security: 2 blocking issues
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[sourcery-ai]

suggestion: Consider adding a maximum limit to the polynomial order

While allowing variable order polynomials provides flexibility, high-order polynomials can lead to overfitting and numerical instability. Consider adding an upper bound to prevent potential issues.

    def __init__(self, order=3, max_order=10):
        self.order = min(order, max_order)

[sourcery-ai]

🚨 issue (security): Potential hard-coded secret found in data dictionary.

The value '7117444122' appears to be a hard-coded identifier or key. Please ensure this is not a sensitive or production secret.

[sourcery-ai]

🚨 issue (security): Potential hard-coded secret found in data dictionary.

The value '6602485156' appears to be a hard-coded identifier or key. Please ensure this is not a sensitive or production secret.