Talk:Requests for comment/Minimalistic MW API Client Lib Specification

Comments by BJorsch (Anomie)
I have no objection to someone doing this, or something like it. But I don't want to be expected to maintain it myself, not least because I'm not very familiar with Python. BJorsch (WMF) (talk) 16:57, 3 June 2015 (UTC)
 * Not a problem, I think we have plenty of python devs around. This lib should simply show "good practices" from the API-devs perspective, as described in the docs. --Yurik (talk) 16:59, 3 June 2015 (UTC)

token
Getting a token using different versions of the API involves three different API calls. See API:Token and API:Tokens (action) for two of them.

Would this API module handle all three versions? John Vandenberg (talk) 05:49, 4 June 2015 (UTC)

console logger?
Doesn't that make it more like a minimal bot framework than a client library? Also, did you consider mwclient? It's supposed to be quite minimal, and you'r welcome to join forces improving it if you like :) Danmichaelo (talk) 20:49, 4 June 2015 (UTC)

Costs of maintenance
I don't think that this addresses real-world issues. I think that it is much more laborious to port a tool to use this library than to watch the API announcements and implement the (very few) breaking changes that occur from time to time.

In addition, while the current breaking change in continuation may be solvable by such a library, I assume most breaking changes will, well, break workflows.

This doesn't mean that there shouldn't be some responsibility on the part of WMF to only deploy when it is sure for example that Pywikibot doesn't break. With MediaWiki and Pywikibot both using Phabricator for task management and talk of setting up Pywikibot as a Jenkins test, this should be easily doable.

Also, it may be useful for Pywikibot to outfactor some functions. As others have pointed out, this should take into account the existing libraries in the field. --Tim&#160;Landscheidt 01:50, 5 June 2015 (UTC)