Client:ask broken ?

[ghost]

Hi all,

as it is , I cannot get Client:ask to work ,

For example, test it on Semantic Mediawiki Sandbox

site=mwclient.Site(('https','sandbox.semantic-mediawiki.org'),'/w/')
query="[[Has email::%2B]]|%3FLabel" 
# see https://sandbox.semantic-mediawiki.org/wiki/Sp%C3%A9cial:Parcourir/:Azure  : this page should be returned by ask
# + note that the arguments must be url encoded (see https://www.semantic-mediawiki.org/wiki/Ask_API )
res=site.ask(query)
res.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/mwclient/client.py", line 960, in ask
    for result in results['query']['results']:

The trouble is : there is no "query" field in the response returned by site.ask() , the api calls returns an error

But you can see the query results here :

https://sandbox.semantic-mediawiki.org/w/api.php?action=ask&query=[[Has%20email::%2B]]|%3FLabel&format=json

Cheers

PS : what is the use of the Title parameter in Client.ask() ?

MB

[ghost]

OK, in client.py

960            results = self.raw_api('ask', query='{query}|offset={offset}'.format(
961                     query=query, offset=offset, http_method='GET'), **kwargs)

should probably be

960            results = self.raw_api('ask', query='{query}|offset={offset}'.format(
961                     query=query, offset=offset) , http_method='GET', **kwargs)

i.e. closing parenthesis after "offset" not "''GET'"

Now it is working with :

• query ="[[Has email::%2B]]"

but not with

• query="[[Has email::%2B]]|%3FLabel"

>>> offset =0
>>> kwargs={}
>>> query="[[Has email::%2B]]|%3FLabel"
>>> results = site.raw_api('ask', query='{query}|offset={offset}'.format(query=query, offset=offset) , http_method='GET', **kwargs)
>>> results
{u'error': {u'query': [u'La partie \xab %3FLabel \xbb de la requ\xeate n\u2019a pas \xe9t\xe9 comprise. Les r\xe9sultats peuvent \xeatre inattendus.']}}
>>> query="[[Has email::%2B]]"
>>> results = site.raw_api('ask', query='{query}|offset={offset}'.format(query=query, offset=offset) , http_method='GET', **kwargs)
>>> results
{u'query': {u'serializer': u'SMW\\Serializers\\QueryResultSerializer', u'version': 2, u'meta': {u'count': 0, u'source': u'', u'time': u'0.000213', u'hash': u'8abf92b9a496fa12811f646f040f3025', u'offset': 0}, u'results': [], u'printrequests': [{u'typeid': u'_wpg', u'redi': u'', u'mode': 2, u'key': u'', u'label': u''}]}}
>>>

[ghost]

OK, all is working now if :

1. the closing parenthesis is put at the right place ( see Client:ask broken ? #153 (comment) )
2. and you don't encode arguments of the semantic query before calling ask

[danmichaelo]

Thx for looking into this! Would you mind opening a pull request for the commits?

[ghost]

Hello I'd like too ! But I'm a git/github newbie. What I've done so far : - I forked the mwclient repository - git cloned my forked repository , made changes, pushed them I opened a pull request (PR) but I closed if because : - the PR contains fixes for issues 149 (fetch login) , 153 and 156 (problems with client.ask()) - the latter are ok , but there are still problems with issue 149, namely :

-- as I implemented it, the unit test login_flow_2 does not pass. I think this is because the new raw_api_call() in mwclient.client.login is not mocked in the unit test - second : I had a misconfiguration in my php sessions configuration. As a result the session was destroyed while my script using mwclient was running. When that happens, any api call gets a "need new token" from MW. In that case mwclient is calling site.get_token() which calls MW api with parameters meta=token. In a private wiki , this calls gets a readapidenied error . Maybe this would happen too with MW instances Anyway I'll open a PR but with commits for 3 Issues, and the one concerning issue 149 is not entirely solved : at least the unit test login_flow_2 should be adapted to pass. I guess I should open a PR for each different issue but I do not know how to do it, or what is the best way to deal with it Cheers Michel

--- Salutations Michel Bénard Le 2017-05-10 14:50, Dan Michael O. Heggø a écrit :

Thx for looking into this! Would you mind opening a pull request for the commits? -- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links: ------ [1] #153 (comment) [2] https://github.com/notifications/unsubscribe-auth/AP9077WXqBMugGdtr1bcM0yyG8TQsm5Tks5r4bKRgaJpZM4NSyGH

[ghost]

- second : I had a misconfiguration in my php sessions configuration. As a result the session was destroyed while my script using mwclient was running. When that happens, any api call gets a "need new token" from MW. In that case mwclient is calling site.get_token() which calls MW api with parameters meta=token. In a private wiki , this calls gets a readapidenied error . Maybe this would happen too with MW instances <1.27

--- Salutations Michel Bénard Le 2017-05-10 15:09, Michel Bénard a écrit :

Hello I'd like too ! But I'm a git/github newbie. What I've done so far : - I forked the mwclient repository - git cloned my forked repository , made changes, pushed them I opened a pull request (PR) but I closed if because : - the PR contains fixes for issues 149 (fetch login) , 153 and 156 (problems with client.ask()) - the latter are ok , but there are still problems with issue 149, namely : -- as I implemented it, the unit test login_flow_2 does not pass. I think this is because the new raw_api_call() in mwclient.client.login is not mocked in the unit test - second : I had a misconfiguration in my php sessions configuration. As a result the session was destroyed while my script using mwclient was running. When that happens, any api call gets a "need new token" from MW. In that case mwclient is calling site.get_token() which calls MW api with parameters meta=token. In a private wiki , this calls gets a readapidenied error . Maybe this would happen too with MW instances Anyway I'll open a PR but with commits for 3 Issues, and the one concerning issue 149 is not entirely solved : at least the unit test login_flow_2 should be adapted to pass. I guess I should open a PR for each different issue but I do not know how to do it, or what is the best way to deal with it Cheers Michel --- Salutations Michel Bénard Le 2017-05-10 14:50, Dan Michael O. Heggø a écrit : > Thx for looking into this! Would you mind opening a pull request for the commits? > > -- > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links: ------ [1] #153 (comment) [2] https://github.com/notifications/unsubscribe-auth/AP9077WXqBMugGdtr1bcM0yyG8TQsm5Tks5r4bKRgaJpZM4NSyGH