Parser and Composer

[TobiasHT5]

So now that we got the necessary objects laid out, we need to work on the system that inter-converts between these objects and the form in which these objects shall be provided to us. So generally our requests and responses shall revolve around deeply nested JSON objects. the JSON objects shall be converted to dictionaries which shall be our mode of converting between JSON and python types.

So basically what we need to do is write a parser that shall receive a request in form of a dictionary and then build out a tree structure using the objects we have. Then we shall also have to build a composer which shall take in the internally generated tree of objects and convert it to a dictionary which shall later be converted into JSON to send back as a response.

I have created a file called parser inside the telegram module. It will have two main classes, that is, Parser and Composer. The work of the Parser class is to house methods used to convert a dictionary into an object tree based on our telegram objects, and the Composer contains methods to convert the object tree back to a dictionary. All the methods of these classes will be private to them, except the parse method for the Parser class and compose method for the Composer class.

Each individual method in the Parser class, except the parse method, shall be responsible for parsing all objects in a given module. The method responsible for parsing objects in a given module shall have a name such as _parse_module-name for example _parse_chat or _parse_proximityalerttriggered. The methods take in a key and a dictionary describing the object to parse and then they construct the object from the given dictionary keys and values. The key tells the parse method which object to create among the many objects it might be able to parse

If a module contains more than one object, The _parse method should be able to parse all the objects in that module, and should be able to identify the particular object that needs to be parsed from the dictionary provided as the argument. For example, the poll.py object contains Poll, PollOptionand PollAnswer, so the parse method _parse_poll needs to identify from the dictionary provided if it needs to create the Poll object or PollOption or PollAnswer and needs to return the created object.

the public parse method shall be the starting point of the parse and shall return the complete tree. usually it shall take in the update object since this is the one provided for every update, so by default this shall parse the update object and then start the chain parsing mechanism

Chain parsing.

We shall use chain parsing to build the tree. This means that if the first method is parsing a dictionary and discovers the presence of another object, it shall pass that portion of the dictionary on to the specialized method for parsing that object. And if the other method discovers another object that it cannot parse, it passes it on to the method that is responsible for parsing that object. In that way, we create a chain of methods to parse the object till it's complete. For example

class Parser:
    def _parse_poll(self,key,obj):
        poll_obj = Poll()   #currently this will give us an error since it needs non-optional args
        #poll_obj can be Poll or PollAnswer or PollOption.
        #It should find the appropriate object based on the key
        for k,v in obj.items():
            if (key == "user"):
                poll_obj.user = self._parse_user(k,v)
            elif (key == "message"):
                poll_obj.message = self._parse_message(k,v)
            else:
                setattr(self,k,v)
        return poll_obj

This is not a real object to parse but it just demonstrates the chain parsing mechanism.

corner cases

write now, object instantiation needs non-optional arguments as a must in order to create the object instance. This will complicate the parsing process by requiring the loop to retrieve the non-optional args first before creating the object instance. It's best to remove this restriction by adding None as the default value of the required args in order to enable recursive building of the objects and adding properties dynamically.
The other corner case is the from_ attribute in some classes, which corresponds to the from property of telegram objects. This is because from is a keyword in python and we can't use it for variables, so care must be taken when parsing an object that contains the from attribute, this includes the message object.

[TobiasHT5]

I'll describe the composer in it's own post, this seemed long enough

[TobiasHT5]

@edger-asiimwe @kallyas @ushergodwin I think I should self assign myself the task of writing the parser and composer while you guys focus on finalizing with the telegram objects. There's still a lot of work to be done there.
I'll write the description of my work here to guide you guys when you hope in later, and also to help the documentation team in the future.

[kallyas]

That's Okay, Incase we are done before you finish up, we can as well as write some

[TobiasHT5]

@kallyas you should help out by adding None as the default value for all the parameters in the __init__ functions of all objects. I don't know how heavy that task is. Also the objects.py module in inline is still missing the concrete implementation of the 4 InputMessageContent classes

[kallyas]

I will do that tonight

[kallyas]

if I understood your point correctly, you mean this

class Poll:
      __slots__ = ('foo', 'barz')
     
     def __init__(self, foo: User = None) -> None
                 self.foo = foo
                 self.barz: SomeType = None

[TobiasHT5]

@kallyas yup, that's it