Perhaps we should remove the code climate badge from README.rst until this issue is fixed.
Is this expected? Shouldn't the API return the default value for dim? ($wgDefaultDim is 1000) (@MaxSem?)
Fri, Apr 20
Thu, Apr 19
Isn't self.write set to False for the api request of self.site.version()? If so, then perhaps this is non-issue since it will never try to call site.version during a version request.
I've not tested, but I think mediawiki interprets &apiparam=False as a true value, i.e. passing the parameter means true and it must be omitted for false.
If so, then I personally find &apiparam=True a little misleading and would prefer to continue using &apiparam= for true values. Others may disagree of-coarse.
Wed, Apr 18
Sat, Apr 14
Wed, Apr 11
Also note the new error message:
Most solutions I found on internet involve compiling Python which requires rewriting the whole installer. I'm too tired for that, giving up.
Still happening, I'll upload a patch soon.
Tue, Apr 10
Sun, Apr 8
Sat, Apr 7
It seems that the first occurence of this error has been in https://ci.appveyor.com/project/Ladsgroup/pywikibot-g4xqx/build/1.0.199/job/jpl92nv4vns79mow (d2efba541308851d549c9b94fa3be1d837617496, March 22). I could not figure out what has changed since then to cause this error.
Fri, Apr 6
Thu, Apr 5
Hasn't occurred in a long time. Also EXTERNALS_HTTPLIB2 flag has been removed in rPWBC952665acaa9a: Switch from httplib2 to requests.
Closing per description ("This ticket should probably be closed if it doesnt re-occur soon.")
Has not occurred for long time.
That line does not exist in the master branch anymore. Removed in 952665acaa9ab2dd1a78cb4a935f3b5743941913.
This seems this task is not valid anymore, perhaps resolved upstream. For example at https://travis-ci.org/wikimedia/pywikibot/jobs/362524887#L2076 we have:
Everything looks fine.
Wed, Apr 4
Mon, Apr 2
With the merge of c25f22164f88b1bf91dd329d0566afed685ce530, this issue will continue to happen on 2.7.2 and 2.7.3. We have not found any better solution yet.
The patch failed to resolve the issue.
On second thought, consuming 100% of CPU (T191113) is not that better than a MemoryError. There must be a better way.
3.4.0 alpha 1 is the first release of 3.4 series and we have dropped support for 3.3.
So we only have this issue with 2.7.2 and 2.7.3.
We could consider dropping support for them but we need a deprecation period. Till then, I suggest using the old regex for those versions.
Sun, Apr 1
Sat, Mar 31
Another case of catastrophic backtracking. This is what happens when we try to parse a context-free language with regular expressions, the ultimate solution is to try using a real parser like mwparserfromhell...
The above patch should fix this specific case, but I have not tested it thoroughly.
I'm gonna close this task as declined.
I'm still getting these warnings.