XZise created this task. XZise assigned this task to jayvdb. XZise added subscribers: pywikipedia-bugs, jayvdb, XZise, Xqt. XZise added a project: pywikibot-core.
TASK DESCRIPTION Before officially releasing 2.0 all code (especially the library) should be PEP-8 compliant and non-compliant code should be marked deprecated. But I also think that this shouldn't be rushed as this gives us a chance to change the method headers for example and improve them without the need to deprecate parts of the new PEP-8 method header.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, XZise Cc: Aklapper, jayvdb, XZise, Xqt, pywikipedia-bugs
jayvdb added a comment.
I agree with the 2.0 library being 'mostly'-PEP8-compliant for the official API, but dont care about scripts (which may not even be packaged in the pywikibot package) and also dont mind if private names (esp. variable names), and argument names are not all compliant.
By 'mostly', I mean the spirit of PEP8 should be complied with, but not the letter of the style guide. e.g. APISite has lots of method names which are comprised of two workds. e.g. unwantedpages. That should be split with an underscore, but doing that is going to create a lot of code churn, new bugs, etc. We currently have scripts which do not work at all , scripts which fail spectacularly when certain args are used, or fail with used on a wiki other than the home wiki of the script writer, usually because an i18n message only exists in one language.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb Cc: Aklapper, jayvdb, XZise, Xqt, pywikipedia-bugs
XZise added a comment.
Well everything we don't deprecate until 2.0 will be also in 3.0 so still in 3.0 some names would need to be guessed. Is it `get_redirect_target`, `getredirecttarget` or `getRedirectTarget`? And as soon as `getRedirectTarget` is deprecated it just could call `get_redirect_target` and if that call fails at some point because of an update, `get_redirect_target` has been broken anyway.
I can agree with private stuff, because those aren't in the official API so renaming them shouldn't be a problem. With scripts it depends if they are packaged, but even when I don't have a problem if those aren't compliant. And I might be okay with some names if they are directly connected with the API. But apart from that it should be consistent, including the arguments because there is the same guessing problem. For example `Page.getVersionHistory` has a parameter `reverseOrder`, so there we could fix both in one step: Just deprecate the method and call the newly added method `get_version_history` which now has `reverse` (or `reverse_order`).
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, XZise Cc: Aklapper, jayvdb, XZise, Xqt, pywikipedia-bugs
XZise added a comment.
Also another thing is that the MW API might change. So a parameter like `fromrev` may might sense now (because it's what the API is using) but maybe MW is changing it to `source` and it doesn't make sense anymore. So having methods named like the API isn't such a good idea after all.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, XZise Cc: Aklapper, jayvdb, XZise, Xqt, pywikipedia-bugs
Ricordisamoa added a subscriber: Ricordisamoa.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, Ricordisamoa Cc: Ricordisamoa, Xqt, jayvdb, Aklapper, XZise, pywikipedia-bugs
jayvdb added a comment.
Another reason to break away from MW API names is those names will be less relevant when we supporting non-MW wikis.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb Cc: Ricordisamoa, Xqt, jayvdb, Aklapper, XZise, pywikipedia-bugs
XZise edited the task description. XZise set Security to none.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, XZise Cc: Ricordisamoa, Xqt, jayvdb, Aklapper, XZise, pywikipedia-bugs
Ricordisamoa added a comment.
In https://phabricator.wikimedia.org/T85328#978852, @jayvdb wrote:
Another reason to break away from MW API names is those names will be less relevant when we supporting non-MW wikis.
Seriously, are we going to support them? More or less four people are developing the framework...
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, Ricordisamoa Cc: Ricordisamoa, Xqt, jayvdb, Aklapper, XZise, pywikipedia-bugs
XZise added a comment.
But even if not, the MW API is not static (see query continue) and thus it's unreasonable to have names which might not make sense anymore in the future. Additionally for someone who doesn't understand how api.php works, this will also confuse further, and what happens if an argument is not directly mapped to something on the API, should that now follow PEP-8 or not?
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb, XZise Cc: Ricordisamoa, Xqt, jayvdb, Aklapper, XZise, pywikipedia-bugs
jayvdb added blocking tasks: T87409: pep8 E402 vs __version__ and others, T87169: run pep8 and pep257 for pywikibot/core.
TASK DETAIL https://phabricator.wikimedia.org/T85328
REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>.
EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: jayvdb Cc: Ricordisamoa, Xqt, jayvdb, Aklapper, XZise, pywikipedia-bugs
pywikipedia-bugs@lists.wikimedia.org