[05:34:18] Definitely, that was probably more a solution in search of a problem thing l, because we did have a drive by nom problem of people just dumping loads of articles for GA review on enwiki, and yeah, it's probably actually better for no -invovled people to nominate (re @Feeglgeef: I specifically disagree with the no-drive-by-noms thing. Users not involved are the [05:34:18] best to nominate imho) [05:36:13] Thank you so much Toby for your edits that made it so much better, just saw them and 100% agree with all of them :) [05:44:18] Yeah, that's actually a great point that I didn't consider, maybe it should be either mostly self-explanatory code or if it's really confusing, explain it with comments in at least 1 language. That rule was inspired by when we were discussing Wikifunctions on the Wikimedia discord server yesterday and there was some discussion about how functions like these [05:44:18] ([[Z20804]], linked to [05:44:19] from the main page) are so confusing because the implementation can't be really understood without looking at the type doc's etc. but I get once you know what the properties mean and the fields of the common types are, it's less confusing and more a way to represent things in an abstract, multilingual way which is good! (re @Toby: I haven't touched the [05:44:19] documentation one yet, bec [05:44:20] ause I have strong reservations about it, and would probably end up pruning it i...) [06:00:18] Fair point. Comments in one language would help that one! (re @MolecularPilot: Yeah, that's actually a great point that I didn't consider, maybe it should be either mostly self-explanatory code or if it's re...) [06:11:43] Even if you read the type conversion docs it would be quite confusing. (re @MolecularPilot: Yeah, that's actually a great point that I didn't consider, maybe it should be either mostly self-explanatory code or if it's re...) [09:42:24] Is Z21617 intended for lexeme form tool? [09:43:13] Or should I create things like ones listed here (https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/Natural_language_operations/Breton) separately [10:35:27] Oh hey, I made that one! Like it's sister functions [[Z21624]] and [[Z21632]], no it doesn't use wikidata lexeme data, if that's what you were asking, it's meant to be more efficient than lexeme data for verbs that follow a regular pattern so you didn't need to list every conjugation for each/subject tense in the lexeme data on every single verb (re@cvictorovic [10:35:27] h: Is Z21617 inten [10:35:28] ded for lexeme form tool?) [10:35:50] Yes, I need that (re @MolecularPilot: Oh hey, I made that one! Like it's sister functions [[Z21624]] and [[Z21632]], no it doesn't use wikidata lexeme data, if that's...) [11:49:33] Python’s way of looking at this is a bit weird imho because it seems to conflate significant figures and decimal places into its concept of “precision”. I’m wondering whether we should add exponential notation to the proposed reader (Z19866)? (re @Toby: Okay as long as you're clear what format you want returned, and at what point it switches to Engineering notation. PS, [11:49:33] also con...) [12:17:24] Thinking about it, if there’s a positive exponent and an otherwise ambiguous thousands separator could be read as such, rather than being assumed to be a radix character. (re @Al: Python’s way of looking at this is a bit weird imho because it seems to conflate significant figures and decimal places into its...) [12:17:39] I think we already get it for free in the floating point reader. We could end up with a funny situation where they both call each other for certain categories of string. (re @Al: Python’s way of looking at this is a bit weird imho because it seems to conflate significant figures and decimal places into its...) [12:19:51] But that's probably a bad plan because it would likely introduce floating point round off errors into the rationals. (re @Toby: I think we already get it for free in the floating point reader. We could end up with a funny situation where they both call eac...) [12:21:29] I don’t see that. The read function for rationals couldn’t use float in any way (even implicitly)! (re @Toby: I think we already get it for free in the floating point reader. We could end up with a funny situation where they both call eac...) [12:22:20] Because of round off? [12:25:32] If(contains_E(string_arg)) return(f_to_q(read_q(string_arg))) is what I was thinking. But I agree it's a bad idea. [12:26:50] I don’t have time right now but I’ll try and get a standalone function up pretty soon, if no one else gets there first. I think it’s reasonably trivial. (re @Toby: Because of round off?) [12:27:20] I like the converse that I already put into read_f that goes like If(contains_/(string_arg)) return(q_to_f(read_q(string_arg))) [12:31:53] Probably just to decimal string rather than directly to rational. (re @Al: I don’t have time right now but I’ll try and get a standalone function up pretty soon, if no one else gets there first. I think ...)