Skip to content

remove some python2 specific code #749

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

Merged
merged 2 commits into from
Sep 7, 2020

Conversation

noviluni
Copy link
Collaborator

I fixed some cases with Python 2 specific code that were detected when removing Python 2 from the pipelines (#744) (https://codecov.io/gh/scrapinghub/dateparser/pull/744/changes)

@noviluni noviluni requested a review from Gallaecio July 17, 2020 15:23
@codecov
Copy link

codecov bot commented Jul 17, 2020

Codecov Report

Merging #749 into master will increase coverage by 0.36%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #749      +/-   ##
==========================================
+ Coverage   95.21%   95.57%   +0.36%     
==========================================
  Files         304      304              
  Lines        2632     2600      -32     
==========================================
- Hits         2506     2485      -21     
+ Misses        126      115      -11     
Impacted Files Coverage Δ
dateparser/languages/loader.py 100.00% <ø> (ø)
dateparser/languages/locale.py 98.64% <ø> (+0.26%) ⬆️
dateparser/utils/__init__.py 97.41% <ø> (+2.59%) ⬆️
dateparser/date.py 99.57% <100.00%> (+0.42%) ⬆️
dateparser/search/search.py 99.33% <100.00%> (+1.28%) ⬆️
dateparser/utils/strptime.py 100.00% <100.00%> (+7.31%) ⬆️
dateparser/search/detection.py 94.33% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05294f8...29ea08a. Read the comment docs.

Copy link
Member

@Gallaecio Gallaecio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the backward-incompatible changes in dateparser.utils, it could be argued that these are internal functions. However, given they are not prefixed with _ and they are listed in the documentation, it may be better to deprecate instead of remove.

@@ -180,7 +174,7 @@ def __init__(self):
self.search = ExactLanguageSearch(self.loader)

def detect_language(self, text, languages):
if isinstance(languages, (list, tuple, Set)):
if isinstance(languages, (list, tuple, set)):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is technically a backward-incompatible change, as it is technically possible for an object to be an instance of a class inheriting from Set that is not a set.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I change it because we accepted as valid this other PR: #509

but now I'm thinking that we should probably keep using Set as it would accept a frozenset for example.

>>> a = frozenset([1,2,3])                                                 

>>> isinstance(a, Set)                                                     
True

>>> isinstance(a, set)                                                     
False

So it is not only "backward-incompatible", but also not desirable. 🤔

@@ -18,9 +18,6 @@ def strip_braces(date_string):


def normalize_unicode(string, form='NFKD'):
if isinstance(string, bytes):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backward-incompatible.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we are going to release a new major version I think it's a good moment to make these backward-incompatible changes. What do you think?

Apart from that, we could also move some of these functions to the private scope by adding a _.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either works. We just need to take this into account when writing the release notes, to make sure we cover backward-incompatible changes.

@@ -44,25 +41,6 @@ def combine_dicts(primary_dict, supplementary_dict):
return combined_dict


def convert_to_unicode(info):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backward-incompatible.

@noviluni noviluni mentioned this pull request Aug 4, 2020
8 tasks
@noviluni
Copy link
Collaborator Author

noviluni commented Aug 30, 2020

I reverted the change in the Set but also the changes introduced by this PR: #509 because I think it's ok to accept frozenset and other "set types". I also rebase against master and fixed the issues.

@Gallaecio, could you check it again?

@noviluni noviluni force-pushed the remove_python2_code branch from ac60a7d to 4ef94a3 Compare August 30, 2020 19:08
@noviluni noviluni requested a review from Gallaecio August 30, 2020 19:09
@noviluni noviluni force-pushed the remove_python2_code branch from 4ef94a3 to 7bec52e Compare August 30, 2020 19:12
@noviluni noviluni added this to the v1.0.0 milestone Sep 7, 2020
@noviluni noviluni merged commit a7ce6c9 into scrapinghub:master Sep 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants