[05:01:03] I am not sure that it's true. (re @dpriskorn: It didn't 😅 [05:01:03] See Task P1.13 in the current version.) [05:41:58] I mean, the page, including that part, was written long before December 2022, and the only significant edit in it after 2022 was marking it as "historical" and "obsolete" last June. So the scope probably changed some time between May 2020 and December 2022. Is anything wrong about my logic? [11:33:24] in case it matters, IMHO it should (eventually?) be in scope (re @amire80: This part is very curious: "As an aside, we gently disagree that large numbers of Lua scripts being manually copied to other wik...) [11:34:52] If you are, by any definition, a Wikimedian, then it matters. [11:45:02] Can someone (especially Al ) check this edit to a built-in function https://www.wikifunctions.org/w/index.php?title=Z889&diff=121269&oldid=92324 which effectively changes the scope of the function a bit. It's in response to Al's creation of an even stricter list equality function Z18646. They would differ in the output on tests like this one Z18656 where the lists have [11:45:02] all the sa [11:45:03] me elements, but they have different overall types. [12:01:45] I find “roughly” a bit unhelpful. I would focus on “…exactly the same elements in the same order (whether or not the list is explicitly typed).” I haven’t checked how list equality (as-was) responds to incorrectly typed lists (an integer prepended to a Typed N-list, for example). If they pass when appropriate, I’d go for “…(ignoring the list’s Type)” (and ad message> [12:01:46] d a comment to your Phabricator ticket). [12:04:04] have I already got a Phab ticket about this?? [12:04:52] About prepend, yes (pretty sure)! (re @Toby: have I already got a Phab ticket about this??) [12:06:36] *T370399* (re @Toby: have I already got a Phab ticket about this??) [12:09:27] Ok. I still think that would be a good feature, but it's not planned, and I've made peace with that. But the behaviour, names and descriptions of our equality functions is much more important. So I'm glad you've figured out this difference. (re @wikilinksbot: T370399 – prepending a different type should untype the list [open]) [12:16:34] Yes. It just affects the wording of the description. We have Z18475 for a general workaround; I just haven’t tried Z889 with incorrectly typed lists yet. (re @Toby: Ok. I still think that would be a good feature, but it's not planned, and I've made peace with that. But the behaviour, names an...) [12:21:32] I guess Z889 is not checking the type at all. I'll try an incorrect type now. (re @Al: Yes. It just affects the wording of the description. We have Z18475 for a general workaround; I just haven’t tried Z889 with inc...) [12:24:20] It passes 😎 (re @Toby: I guess Z889 is not checking the type at all. I'll try an incorrect type now.) [12:25:30] I’ll publish in a bit if you haven’t already 👍 (re @Toby: I guess Z889 is not checking the type at all. I'll try an incorrect type now.) [12:36:19] Go for it. I got distracted by the women's omnium :) (re @Al: I’ll publish in a bit if you haven’t already 👍) [12:36:49] Z18658 (re @Toby: Go for it. I got distracted by the women's omnium :)) [12:45:18] Here is another: v [12:45:19] Z18659 [12:46:50] the composition can't cope with yours, but passes mine [12:51:12] 🤔 Any idea why that is? (re @Toby: the composition can't cope with yours, but passes mine) [12:55:41] nope (re @Al: 🤔 Any idea why that is?) [13:15:45] Could it be another hidden timeout? These tests are getting a bit complex. Even the built-in takes 7732ms for my test. (re @Al: 🤔 Any idea why that is?) [13:28:51] With neither the test nor the implementation connected, it’s a bit too ultra-niche for me… How do you feel about deleting Z16308? I think we agreed it should be a separate function (“same objects” for strict object equality). (re @Toby: nope) [13:30:56] No, Z13053 🙄. I’ll request formally… (re @Toby: Could it be another hidden timeout? These tests are getting a bit complex. Even the built-in takes 7732ms for my test (longer th...) [13:34:22] Yes, we can delete this, or move it to an exact object equality. (re @Al: No, Z13053 🙄. I’ll request formally…) [13:35:35] This I want to keep, but keep disconnected. It helps to show the difference between the implementations, but shouldn't really condemn either implementation. (re @wikilinksbot: Z16308 – 1 != January (but it is when mapped in python)) [13:40:55] Happy either way… I just connected it because the metadata was showing an error in the new implementation even though it passed. It seems okay now 🤷‍♂️ (re @Toby: This I want to keep, but keep disconnected. It helps to show the difference between the implementations, but shouldn't really co...) [13:55:45] if it's connected, the python implementation might have to be disconnected according to https://www.wikifunctions.org/wiki/Wikifunctions_talk:Best_practices#Connecting_implementations (re @Al: Happy either way… I just connected it because the metadata was showing an error in the new implementation even though it passed....) [14:02:53] Disconnected. I’ll agree with the Best practice and propose its adoption, given support without dissent. (re @Toby: if it's connected, the python implementation might have to be disconnected according to https://www.wikifunctions.org/wiki/Wikif...) [17:17:51] /delete@wikilinksbot (re @wikilinksbot: P1) [19:12:14] It isn’t a timeout. The Python implementation of object equality fails for your two lists. The contains composition succeeds, but only if the untyped list is the second list (see Z18676, where the order is reversed). This gives the same error as Z18658. It looks like a type conversion error: "cannot read property 'Z6K1' of undefined". This should not be a surprise! I’ll [19:12:14] try t [19:12:15] o provide an explanation on Z18653 but, assuming it’s an inconsistency that applies only to mis-Typed lists, I’ll do my best not to fret about it 😏 (re @Toby: Could it be another hidden timeout? These tests are getting a bit complex. Even the built-in takes 7732ms for my test (longer th...)