[03:08:21] Is it “typed list” in engine? [03:08:47] What if I would like a list regardless of type? [03:09:22] Type it with object [03:09:50] Everything is an object, so that will work [03:09:53] For example, I’d like to create some functions for general list operations, that doesn’t require list elements to be specific type [03:10:29] Yep, all the functions that are built-in and mentioned in the newsletter are like that [03:10:52] Only five [03:11:14] Now that I’m going to create a function for “reversing a list” [03:11:47] Yes, you can create more. Just saying that those are examples of functions on basically untyped lists [03:12:38] Oh now I understand, “object” is a type of wildcard [03:15:47] Exactly [03:28:37] Which output function of python is engine using [03:28:46] Not print, right? [03:29:26] Huh? I don't understand the question [03:29:43] def Z12668(Z12668K1): [03:29:44] i = len(Z12668K1) - 1 [03:29:45] while (i >= 0): [03:29:47] print(Z12668K1[i]) [03:29:48] i -= 1 [03:30:04] You need to return a list, not print it [03:30:20] And test case isn’t passing, I doubt print shouldn’t be used here [03:32:20] Try return Z12268K1.reverse() [03:32:45] With the correct ZID [03:36:25] Validate object [03:36:42] Is this equality function for any object type? [04:02:14] No, it's validation, not equality [05:08:31] Then what should I use for a test case involving list? [07:37:08] Hi, I've updated my tool at https://wikifunc-labelize.toolforge.org/editor, you can now easily try it out with the "editor" page now, and it was still using the beta cluster's data, now it uses wikifunctions.org. Hopefully someone will find the tool useful. [07:43:42] Oh also let me know if you can think of a better name for the tool, I'm bad at naming things [08:39:37] Z889 is the function for testing whether two lists are equal. (re @cvictorovich: Then what should I use for a test case involving list?) [08:54:48] Element of equality? (re @Al: Z889 is the function for testing whether two lists are equal.) [09:08:58] When the type is Z1? I don’t know. (re @cvictorovich: Element of equality?) [09:17:41] Z12670 [09:23:34] Still no int right? 😭 (re @wmtelegram_bot: Our first newsletter for 2024 is out, and we are announcing a new datatype: Lists! - https://meta.wikimedia.org/wiki...) [09:27:24] Not yet, but since list are done (more or less) I guess number (should it be "int" btw?) are probably next (re @Egezort: Still no int right? 😭) [09:52:38] This is still in the works (re @Egezort: Still no int right? 😭) [09:53:03] Can't promise about timings yet, but we're working on it [10:34:10] I have no idea regarding signed unsigned etc. But I think that it should be int in the beginning and float stuff later (re @Nicolas: Not yet, but since list are done (more or less) I guess number (should it be "int" btw?) are probably next) [12:27:59] now that lists are available: some of the German functions should really return lists, e.g. Z11991(Haus) = [Haus], but Z11991(Kind) = [Kinds, Kindes] [12:28:21] in that case, should I change the existing function (signature, implementation(s), test(s)), or create a new function instead? [12:33:13] I would say create a new function (because some people may want only one form and don't need the full list) (re @lucaswerkmeister: in that case, should I change the existing function (signature, implementation(s), test(s)), or create a new function instead?) [15:49:42] It is not the case that every type can offer an equivalency function, unfortunately. Therefore there can't be a general equivalency test that works for all Objects, maybe even across types (re @Al: When the type is Z1? I don’t know.) [16:00:57] That’s what I thought. But all objects ultimately have string representations, so it should be possible to test for canonical or normal object equivalence (with representational equivalence being string equality). (re @vrandecic: It is not the case that every type can offer an equivalency function, unfortunately. Therefore there can't be a general equivale...) [16:08:00] I would change the existing function. the only reason it didn't return multiple originally was because it wasn't possible to, not because anyone wanted it to only pick one (re @lucaswerkmeister: in that case, should I change the existing function (signature, implementation(s), test(s)), or create a new function instead?) [16:17:36] in general I would say it's ok to update functions once functionality becomes available if that's what it was intended to be (similar to the discussion about strings versus numbers the other day)... I would check with the person who created the function first though, if it's not one you made yourself [16:48:24] I don’t find that very convincing tbh… there are several possible forms and IMHO people should be aware of that (re @Nicolas: I would say create a new function (because some people may want only one form and don't need the full list)) [16:49:13] they can still take the first element of the list if they want, but I think throwing the other forms away should be a choice on their part [16:49:29] Hmmmm 🤔 [16:49:30] (I created that function, see [[Talk:Z11991]]) (re @Nikki: in general I would say it's ok to update functions once functionality becomes available if that's what it was intended to be (si...) [16:50:15] It's absolutely true but I'm struggling to see what would be best... [16:51:41] Also, is the first item of the list the same one ? (to be consistent and not mixing different forms/registers/lects in the same text) [16:53:22] it could be, I guess [16:54:02] My main interrogation is: when does the choice happens? Before: the user chooses the specific function or after: the general function chooses the result. And in the second case, what input allows the function to choose? (re @lucaswerkmeister: they can still take the first element of the list if they want, but I think throwing the other forms away should be a choice on ...) [16:59:09] I’m not sure what you mean [17:15:32] Me neither 🤪 (re @lucaswerkmeister: I’m not sure what you mean) [17:17:54] But if there is 2 possible forms and since you need only one in a generated text in the end, I'm wondering when/where/how should the selection be made (and how to be consistent and correct) [17:18:59] it’s a bit of an open question, admittedly [17:19:15] Wikidata Lexeme Forms just creates several forms with no distinguishing features at the moment [17:19:17] Because you can write like a duke of Bavaria or like a doner seller from Berlin, but you can't switch from one to the other in the same text 😂 [17:20:15] And I'm very interested because it will be needed *a lot* in Breton 😉 [17:21:46] that sounds like a challenge (re @Nicolas: Because you can write like a duke of Bavaria or like a doner seller from Berlin, but you can't switch from one to the other in t...) [17:22:25] I would prefer if we made a new function instead of updating an existing one. The problem with updating existing ones is that it might be in use somewhere and that will break now. In this case, the Lexeme forms, but Lucas would be the one there too. So because the project is still so early, we can get away with updating it, but I think that would be setting bad precedent. I'd pre [17:22:26] fer us to create a new function, and potentially deprecate the other one. Also the system isn't really well equipped with changing signatures of functions. But this I'm saying as a community member, not as project lead. [17:22:51] do we have a way to deprecate functions? [17:23:00] or do we just put “deprecated” in the label? ^^ [17:24:19] I would put the talk page into category deprecated function. It would make sense to eventually have an approach better supported by the system than that. [17:25:53] I worry about setting a bad precedent too, but I'm also concerned about us ending up with a load of functions that were just hacks to work around missing types/functionality. maybe it would be better to delete them, but that will break anything using it too [17:27:00] In many cases the old functions can be thin shims over the new better functions [17:27:08] and I still think we should make it clear when something is only temporary, so that anyone who uses it knows they're using it at their own risk :P (re @Nikki: it would be good to make it clearer in the descriptions when it's only temporarily using strings, though) [17:27:37] Agree with that (re @Nikki: and I still think we should make it clear when something is only temporary, so that anyone who uses it knows they're using it at...) [17:41:37] has anyone made any JavaScript implenentations which return lists? [18:39:59] I just made one on Beta, Z11565 [18:40:45] https://wikifunctions.beta.wmflabs.org/view/en/Z11565 [18:41:22] Let me know if that helps. Also happy to jump in and help with a specific implementation if there's trouble