[01:32:58] Pine, #mediawiki is the best channel for non-wikimedia tech questions. (Someone did reply to you yesterday ("what's the error message?") but you timeout-disconnected a couple of minutes afterwards.) [01:34:12] OK thank you [13:46:51] Hi. How can I tell if a gadget is 'default on' from the database? [14:03:08] Niharika, I think you either need memcached access or to parse the definitions page? [14:08:19] Krenair: Hmm. Okay. If I look at user_properties, a value of 0/'' will indicate an opt-out of a default gadget then, right? [14:15:08] Nope. Apparently not. [15:09:48] Niharika, are you doing this from the context of a MW extension? [15:10:53] Krenair: A SpecialPage. Extending QueryPage. [15:11:28] So you should be able to get the default gadgets, just not through the database [15:13:40] Niharika, see how this does it: https://phabricator.wikimedia.org/diffusion/EGAD/browse/master/GadgetHooks.php;HEAD$52-66 [15:13:54] Krenair: Umm, how? [15:14:00] This is in reference to: https://phabricator.wikimedia.org/T115152 by the way. [15:14:02] Okay. [15:14:41] That looks easy, thanks Krenair! [16:38:11] o/ yurik [16:38:12] https://github.com/mediawiki-utilities/python-mwapi/pull/22 [16:38:33] * yurik looks [16:42:26] halfak, i think that separating post() vs get() is much less prominent (its an internal requirement really) vs the fundamental usage of the function. [16:43:25] performing an auto-continuing set of queries differs from a single action/get request [16:43:36] * halfak tried to interpret that sentence and fails [16:44:00] halfak, you are introducing post() & get() [16:44:07] I am? [16:44:14] you have before [16:44:34] i mean you have structured the code around this separation [16:44:47] post() and get() were in the library I inherited from Yuvipanda [16:45:00] post() and get() are also standard in `requests` [16:45:26] right, but in request they make sense - as they are helper functions [16:45:26] They are the recommended access pattern for sending/receiving requests [16:45:36] They are helper functions here too [16:45:48] Note that request() performs all of the bits that get() and post() do [16:46:01] And get()/post() just pass values to request() [16:46:06] sec, i'm talking about the general approach here, let me try to explain: [16:46:21] * halfak prepares for explanation [16:47:15] request lib is all about the requests, so it offers different ways of doing that. This lib is NOT about requests, its about access to API. So it should structure its functions around the api capabilities, not the internal functioning of the interface between the lib and the host [16:47:42] But the API is also based on requests [16:47:54] of course, but that is an implementation detail ) [16:48:06] And the developer will likely be concerned about how they access the API. [16:48:19] so it should offer functions like login(), call(), multiple_calls(), pages() [16:48:40] in other words - structure it from the perspective of what user is trying to do - which is to call the api [16:48:53] Nope. [16:48:56] not around the minute internal interface specific of get vs post [16:48:59] User is trying to get a list of revisions [16:49:06] So why not api.revisions.query()? [16:49:16] User isn't trying to "call" anything. [16:49:34] yurik, call == request [16:49:43] halfak, that's a fair point, but that means the api lib will have to know and wrap each api capability -- which is something that higher level lib will do [16:49:56] at this level, we should offer the minimum "call()" functionality that other libs will use [16:49:57] No, quite the opposite [16:50:05] ? [16:50:06] Yes. That is what is done. [16:50:10] We don't call it "call" [16:50:17] Are we bikeshedding a function name? [16:50:29] And the presence of some helper functions (get/post)? [16:50:37] i didn't mean to concentrate on the function names )) [16:50:49] i meant to use different words just to highlight the functionality [16:50:57] how you call them is a different discussion ) [16:51:11] Yes. What functionality is missing [16:51:13] ? [16:51:50] my point is that you shouldn't highlight the internals of the communication, as in get() vs put(), but instead highlight the functionality: singlecall() vs multiplecalls_yieldable() [16:52:12] I'm not going to name a function multiplecalls_yieldable() [16:52:23] Or singlecall() [16:52:29] I don't see how that is any more clear [16:52:29] forget abotu the names, only look at the meaning ))) [16:52:49] this way you wont have as many WTF when people try to use the get() and pass in continuable [16:53:08] Are you just trying to say that you'd prefer a helper function for continuation? [16:53:17] ye [16:53:18] yes [16:53:25] Say that then. [16:53:28] )) [16:53:30] i am! [16:53:34] I discuss that in the PR [16:53:50] yes, but i wanted to talk to you directly about it here [16:54:22] my point is that we should hide the get/post -- refactoring them into a single method, and have one method for "multiple calls" [16:54:49] Well, first of all, we're not going to get rid of get/post for backwards compatibility reasons. [16:54:50] but don't let get/post handle the tricky continue stuff [16:55:00] "tricky" 5 lines of code [16:55:01] mark them as obsolete )) [16:55:17] by tricky i mean mental understanding by the users )) [16:55:30] I have higher expectations for my users, I guess. [16:55:39] yurik, can we move past your disagreement with the get/post design decision [16:55:46] I inherited it and I think it is a fine one [16:55:49] i have been coding far too long, i don't ))) [16:56:07] yurik, shall we compare our resumes? [16:56:09] its more of a - don't put any continuation stuff inside the get/post [16:56:30] ^ not an argument. [16:56:35] halfak, i don't think we will find elusive "i had horrible experience with other devs" in it ;) [16:56:37] Just saying "don't" is not a reason [16:56:55] that's an opinion ))) [16:56:59] my opinion [16:57:04] yurik, I did software engineering for 4 years before gradschool and I spent the last decade building software with academics. [16:58:06] halfak, we are not comparing resumes! i just said i had bad luck with ppl misuing my code ))) its not a contest ;) [16:58:36] please re-read what i said if you don't believe me )))) [16:58:51] Well, you claimed that your opinion was based on the length of time you spent coding. This is not a contest, but I've been coding for a long time too, so the argument is kinda a pissing contest. [16:59:03] sigh [16:59:16] Regardless, I need a *reason* to refactor and/or a proposal for how it can be done better [16:59:25] So far I've heard "deprecate get/post" [16:59:33] and "rename request to call" [16:59:39] And "it's my opinion" [17:00:41] so my point - lets introduce easy to understand functions that don't hide complex functionality behind parameters. I think that get()/post() should not have different output type based on the param. Instead i think we should direct lib users towards either a) a single call pattern, or b) a multi-call yieldable pattern [17:01:21] if you want to keep get()/post(), sure, keep them, just specify explicitly that they are targeted towards a single call usecase [17:01:54] in any case, underneath it all we should have a proper way for the higher-level lib to specify a callback for error management [17:01:57] such as retries [17:02:01] So, a "continuation()" helper function [17:02:06] sure [17:02:11] Cool. I can do that. [17:02:16] however you want to call it ) [17:02:26] just don't let ppl overload the meaning of get() [17:03:23] I'd rather let people do what they want and give them some nice intuitive options. [17:03:37] I agree that some may find an explicit method for continuation intuitive [17:03:40] So off I go! [17:03:41] Thanks [17:05:54] halfak, thx ))) didn't anticipate such a heated discussion ))) [20:02:13] [[Tech]]; 82.173.153.25; /* White background is more radiant and thus costly ecologicly. Would prefer black background, white letters. */ new section; https://meta.wikimedia.org/w/index.php?diff=14273797&oldid=14247710&rcid=6921809 [21:12:43] [[Tech]]; Ruslik0; /* White background is more radiant and thus costly ecologicly. Would prefer black background, white letters. */; https://meta.wikimedia.org/w/index.php?diff=14274545&oldid=14273797&rcid=6921913