Skip to content
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

refactor PluginIndexes.unindex.UnIndex.query_index fixing #55 and #56 #57

Closed
wants to merge 5 commits into from

Conversation

d-maurer
Copy link
Contributor

@d-maurer d-maurer commented Mar 8, 2019

Fixes #56

@d-maurer
Copy link
Contributor Author

d-maurer commented Mar 8, 2019

@ale-rt

I think it should be if not six.PY2 and isinstance(code, six.binary_type)

I assume you wanted to comment on @icemac 's "widcode" changes (which is Python2/Python3 dependent). My PR is independent of Python 2/3 (and "six").

@d-maurer d-maurer requested review from icemac, ale-rt and hannosch March 8, 2019 14:08
@ale-rt
Copy link
Member

ale-rt commented Mar 8, 2019

You are right @d-maurer I was commenting on the merge commit :)
Did not follow a lot the development recently but it seems master already has a problem here:

def decode(code):
# Handle bytes that were not properly decoded during Python 3 conversion
if not isinstance(code, str):
code = code.decode('latin1')
# Decode a string into a list of wids.
get = _decoding.get
# Obscure: while _decoding does have the key '\x80', its value is 0,
# so the "or" here calls _decode('\x80') anyway.
return [get(p) or _decode(p) for p in _prog.findall(code)]

On Py2 decoding text (if possible) will return again text:

     if not isinstance(code, str): 
         code = code.decode('latin1') 

I will open an issue for that (see #58)

Copy link
Contributor

@hannosch hannosch left a comment

Choose a reason for hiding this comment

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

Sorry, there are too many changes here for me to review this. Given that in addition #55 is based on a misunderstanding, I can't approve this.

Copy link
Member

@icemac icemac left a comment

Choose a reason for hiding this comment

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

I do not know the code enough to feel competent to review this PR.

@d-maurer
Copy link
Contributor Author

@hannosch has convinced me that #55 is not a bug.

In my view, the code in Products.PluginIndexes.unindex.UnIndex.query_index is horrible (difficult to understand, difficult to maintain, difficult to read) but apparently, it does work.

A refactorisation would have helped me with the upcoming version of Products.AdvancedQuery. But, meanwihile I have found an (even more general) approach: AdvancedQuery will use the elementary indexing information but implement the filtering itself. Thus, I am no longer interested in the quality of the base implementations -- but still will keep you informed about bugs I detect (or think to have detected).

@d-maurer d-maurer closed this Mar 12, 2019
@jensens jensens deleted the resultset_intersection#55 branch June 24, 2019 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants