Gacha_response modification #11
No reviewers
Labels
No labels
Bug
Feature
Feedback Wanted
Refactoring
Won't Do
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: waifu/kemoverse#11
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Referencing issue #3
@ -0,0 +31,4 @@'''Given a command with arguments, processes the game state andreturns a response'''command, full_user, arguments, note_obj = parsed_commandNice 🎉
@ -4,3 +3,3 @@def parse_notification(notification,client):'''Oarses any notifications received by the bot and sends any commands to'''Parses any notifications received by the bot and sends any commands tothis saves the west
@ -47,1 +48,3 @@note = notification.get("note", {}).get("text", "")note = notification.get("note", {})note_text = note.get("text", "")note_id = note.get("id")I love these little things, thank you
Idk why it's in "request changes", all good here
@ -50,0 +53,4 @@# We want the visibility to be related to the type that was received (so if# people don't want to dump a bunch of notes on home they don't have to)visibility = notification["note"]["visibility"]I understand the intent, but you have to put an unchecked box in your head, that now you
bot_app.pyis VERY heavily depending on Misskey notification notations and API. If you still want to aggregate all Misskey specifics to one place, this move makes it a bit harder for the future.Like in chess, with this opening your
parse_notificationis cleaner now, butbot_appis ""dirtier"" . So think about next movesIdk why it's in "request changes", all good here, it's just an observation
@ -56,0 +70,4 @@# 🧠 Send to the parserparsed_command = parse_notification(notification,client)# Get the responseresponse = generate_response(parsed_command)You are doing neat tuple unpacking at response.py, but here you don't. Would be cool to unify your approach and do the same with
responseobject here! The intention would be a lot clearer[text, file_ids] = generate_response(parsed_command)and then
if empty(file_ids): ...I think I can't do [text, file_ids] = generate_response(parsed_command) if file_ids don't exist, it will try to unpack two values anyways and throw an error, would it be better in this case to make sure that the output is always [text,file_ids(possibly None value)]?
Moving to a 1.1 pr to make it more official
Pull request closed