| ghostmansd[m] | lkcl, I cannot cope with this energetic vampirism. It's unfair and rude. | 06:51 |
|---|---|---|
| ghostmansd[m] | I put a lot of efforts into the project. Almost all my free time goes here. I don't deserve such treatment. | 06:57 |
| lkcl | ghostmansd[m], i know - i'm really sorry i can't express these things clearly. normally in a Corporate environment there would be a "Project Manager" whose job it is to "lay down the law / set the rules" | 08:23 |
| lkcl | i know these things have to be done: i just don't know how to express them in ways that are... ahh... "kind"? "acceptable"? | 08:24 |
| lkcl | so i'm really sorry, i do have to keep in mind the entire codebase, and how to ensure it's navigatable | 08:26 |
| lkcl | remember, i'm the one "keeping it all together" so if something stops me from being able to do that, it's a big problem | 08:26 |
| lkcl | and please don't think for one second that i don't know how incredibly valuable what you're doing is. | 08:27 |
| lkcl | having a machine-readable instruction database is... well it's everything. it's literally the core of the entire project. | 08:28 |
| ghostmansd[hexch | Leave it, you don't sorry. It's not about the rules per se, it's about how you establish them. | 08:31 |
| ghostmansd[hexch | Rules should be reasonable and consider real world around. | 08:32 |
| ghostmansd[hexch | What exactly is wrong with "path"? | 08:32 |
| lkcl | i know - please remember i have neurologically-related communication difficulties. i'll do my best to write it up over a few days, it will take me a while | 08:35 |
| ghostmansd[hexch | There's no module named path in standard Python. But, even if there was, it should not be forbidden to name anything this way. Moreover, even standard libraries in Python are fine with naming methods and properties like type, id. | 08:35 |
| *** ghostmansd[hexch is now known as ghostmansd | 08:36 | |
| * lkcl running all unit tests in the paths branch, one quick test worked great | 08:37 | |
| ghostmansd | My particular problem is that, whenever you enforce something, there should be a clear rationale. | 08:37 |
| lkcl | it's better if i write the answers down in the developer guide | 08:37 |
| lkcl | there is - i just need time to write it down in the developer guide. it'll take me a few days | 08:37 |
| lkcl | so sorry i need to get ready to go to the airport. tests running. | 08:38 |
| ghostmansd | tests are already running in CI | 08:39 |
| lkcl | ok they're good. all passed | 08:49 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:43 | |
| *** ghostmansd <ghostmansd!~ghostmans@109.173.83.100> has joined #libre-soc | 10:44 | |
| *** ghostmansd <ghostmansd!~ghostmans@109.173.83.100> has quit IRC | 11:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 12:05 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.147> has joined #libre-soc | 12:05 | |
| ghostmansd[m] | programmerjake, I thought more on indices and paths. Perhaps this stuff can just be called identifier, and can be converted to int/str. | 12:07 |
| ghostmansd[m] | Because logically this is just an identifier in an container which had the element. | 12:13 |
| ghostmansd[m] | And, if such ID is itself a node, it can be visited too. If we have difficulties integrating the path into the elements, why not yield that path as a separate node? | 12:16 |
| ghostmansd[m] | That's just a crazy idea, but should work. | 12:17 |
| ghostmansd[m] | Also, I thought that perhaps visitormethod should be less strict. Currently it uses type(node) to find an associated handler and match is 1:1. But perhaps we should consider classes MRO hierarchy. This way, for example, something can be matched loosely too, allowing to handle "any dataclass" or "any tuple" or whatever. | 12:22 |
| ghostmansd[m] | When we have node, traverse MRO, and call the visitor handler on the first matched class. Otherwise call the generic method. | 12:26 |
| *** octavius <octavius!~octavius@92.40.169.50.threembb.co.uk> has joined #libre-soc | 13:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.147> has quit IRC | 13:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:37 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.156> has joined #libre-soc | 13:43 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.156> has quit IRC | 13:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.156> has joined #libre-soc | 14:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.156> has quit IRC | 14:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.30> has joined #libre-soc | 14:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.168.30> has quit IRC | 14:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:27 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:33 | |
| *** rsc <rsc!~robert@fedora/rsc> has quit IRC | 14:35 | |
| *** rsc <rsc!~robert@linuxnetz.de> has joined #libre-soc | 14:35 | |
| *** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc | 14:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:37 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:43 | |
| *** tplaten <tplaten!~tplaten@195.52.60.179> has joined #libre-soc | 16:06 | |
| *** pangelo[m] <pangelo[m]!~pangeloma@2001:470:69fc:105::3ec5> has joined #libre-soc | 17:10 | |
| *** tplaten <tplaten!~tplaten@195.52.60.179> has quit IRC | 17:50 | |
| *** octavius <octavius!~octavius@92.40.169.50.threembb.co.uk> has quit IRC | 18:08 | |
| lkcl | lol down the rabbit-hole on visitors calling visitors - it's never-ending | 19:16 |
| lkcl | lib2to3 does much of this stuff, with full-on XPath-style pattern-matching | 19:17 |
| programmerjake | imho the ID isn't that useful by itself, it should just be passed into the visitor when visiting the corresponding value | 19:20 |
| programmerjake | so i don't think visiting the ID is what users will want | 19:21 |
| programmerjake | so the visitor method could be like: | 19:23 |
| programmerjake | @visitormethod(BlahNode) | 19:23 |
| programmerjake | def visit_BlahNode(self, key, value): ... | 19:23 |
| programmerjake | where key is the field index/name and value is the BlahNode instance | 19:24 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:39 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:39 | |
| ghostmansd | programmerjake, that was my idea too. At this point, all questions on this are to be addressed to Luke. | 19:57 |
| *** klys <klys!~mdasoh@show.op8.us> has quit IRC | 21:31 | |
| *** klys <klys!~mdasoh@show.op8.us> has joined #libre-soc | 21:31 | |
| ghostmansd | I needed some sort of distraction, so I played around walkers and visitors as standalone idea: https://bugs.libre-soc.org/show_bug.cgi?id=1094#c132 | 21:46 |
| ghostmansd | That's just a concept. It is on standalone Git repository (repo.or.cz). Perhaps I'll even allow mob development, but not now. | 21:48 |
| programmerjake | you forgot a sw license | 21:48 |
| ghostmansd | This is just for you to take a look if you have some free time. I don't yet plan to integrate it anywhere. | 21:48 |
| ghostmansd | Thanks for reminder on license, added | 21:56 |
| ghostmansd | 2-clause BSD | 21:56 |
| ghostmansd | for real pirates | 21:56 |
| programmerjake | looks nice to me, though you may want users to have to use contextmanager separately from hook since iirc it works better for type detection and stuff for mypy or pyright or similar | 21:59 |
| programmerjake | so: @hook(MyClass) | 22:01 |
| programmerjake | @contextmanager | 22:01 |
| programmerjake | def visit_MyClass(self, instance): | 22:01 |
| programmerjake | oh, also, visitor methods are supposed to start with visit_ but Visitor.object doesn't | 22:02 |
| ghostmansd[m] | Hm. This will lose the enter/exit then... But I think you're right, explicit is better than implicit. Likely most users only need "call Y on X", not "before X do Y, then pass the control, then do Z". | 22:09 |
| ghostmansd[m] | It is :-) | 22:09 |
| ghostmansd[m] | The thing is that the original name is discarded. | 22:09 |
| ghostmansd[m] | This can be named anything. | 22:10 |
| ghostmansd[m] | The metaclass constructs the method name under the hood. | 22:10 |
| programmerjake | it won't lose enter/exit since @contextmanager still does that | 22:10 |
| ghostmansd[m] | No, I mean, if somebody misses @contextmanager. | 22:10 |
| ghostmansd[m] | But perhaps they might opt this intentionally... | 22:11 |
| ghostmansd[m] | I'll think about it. | 22:11 |
| ghostmansd[m] | The trick is that the dispatcher metaclass constructs the name. I could've used even lambdas there. | 22:12 |
| programmerjake | well, if they miss contextmanager then standard python rules take effect: either they construct a context manager some other way or `with` throws a TypeError | 22:12 |
| ghostmansd[m] | Yeah, fair enough. | 22:12 |
| programmerjake | rather than the metaclass renaming methods, i think it's better for the metaclass to just check method names, since python type checkers won't understand the method renames | 22:15 |
| programmerjake | plus, this is confusing: | 22:17 |
| programmerjake | @hook(MyClass) def blah(self, instance): ... | 22:17 |
| programmerjake | def foo(self): self.visit_MyClass(MyClass(...)) # calls blah?! | 22:17 |
| ghostmansd[m] | Sometimes names might be complex. What if two different classes in different modules are needed to be used simultaneously? | 22:17 |
| programmerjake | well, the names include the full module path... | 22:18 |
| ghostmansd[m] | Yes, but that's thanks to the renaming. | 22:18 |
| ghostmansd[m] | Making a user doing this manually would be a disaster. | 22:18 |
| ghostmansd[m] | As for type checkers... I think that's what functools.wraps do. | 22:19 |
| ghostmansd[m] | This should update the wrapped function respectively, shouldn't it? | 22:19 |
| ghostmansd[m] | The name, the docstring, etc. | 22:20 |
| programmerjake | wraps doesn't tell the type checker that magically the function has a different name | 22:20 |
| ghostmansd[m] | It changes the name, that's for sure. | 22:20 |
| programmerjake | plus type checkers often ignore most annotations since they don't interpret them | 22:20 |
| programmerjake | so it expects @foo def bar() to always be named bar | 22:21 |
| ghostmansd[m] | Hm. I think I'll refactor this a bit so that the metaclass accepts the original function as well. | 22:22 |
| programmerjake | they tend to also ignore most metaclasses, with a few hardwired exceptions | 22:23 |
| ghostmansd[m] | Then, if the callers need the function to be renamed, they can handle it on their own. | 22:23 |
| ghostmansd[m] | Well, metaclasses are a must there. | 22:23 |
| ghostmansd[m] | (could've used type() instead, that'd be evil) | 22:23 |
| programmerjake | yeah, but if you don't rename functions then mypy ignoring the metaclass still means it can correctly resolve when someone does self.visit_foo() since the metaclass didn't rename it | 22:25 |
| ghostmansd[m] | Ok, so I think the correct approach would be keeping names as is by default (that is, whatever the caller typed). If users have different classes named the same — it's up to them to come up with the naming. | 22:25 |
| ghostmansd[m] | And point that the methods are expected to be named walk_ or visit_, but don't enforce it. Just require the names to be unique. | 22:26 |
| ghostmansd[m] | Oh, I forgot to mention another cool feature. The same handler can be installed for a set of classes. The default walker installs one handler for list, tuple, set and frozenset. | 22:27 |
| ghostmansd[m] | This could be worked around by having some method with common logic and separate handlers which all call that common method, but I suspect this is quite a common scenario. | 22:28 |
| programmerjake | hmm, an alternative scheme: try visit_full_module_path_MyClass, then try visit_MyClass, that way non-conflicting names can just use the short version, but conflicting names use the full module path version | 23:01 |
| *** libredev <libredev!libredev@libredev.ircforever.org> has quit IRC | 23:08 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 23:12 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 23:13 | |
| *** libredev <libredev!libredev@ircforever.org> has joined #libre-soc | 23:16 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!