Converting to draft as few corner cases need to be checked and the symbolics_05.py test file needs to be updated with these cases.

The has attribute can be added to the set of attributes once #2336 is merged. We can first merge this and then rebase that pr on top of this I think !

Thanks! I need to think about if this is the right way to fix it. It seems to be adding symbolics stuff into the frontend at places where maybe it shouldn't belong. I'll get back to you.

Yeah I sometimes was suspecting if this is moving in the wrong place but then let's say we have pi.diff(x), the ast treats pi like any other name and if we run the program, it throws back the error saying the variable pi wasn't defined, hence I felt that we could try fixing this right from where the error spawns up which was handle_attributes.
So essentially there are 3 blocks

1. For constants
2. For binary opertors
3. For functions

I think so we could stick to this but I am also not sure if we could do better !

@czgdp1807, @Thirumalai-Shaktivel, @Shaikh-Ubaid any ideas how to best support this? We want to support custom SymPy methods, but do not want to pollute the frontend at the wrong places. I think this is similar to custom NumPy methods that we support (or will support).

As Anutosh said, the constant like pi will be treated as variable and it is not declared in current scope, the same goes for function call as well.
So for that, I think:

1. We can add a new node (let's say SymbolicItems or SymbolicObjects) and handle this in the Symbolic pass.
2. We can add more symbols like SymbolicFunction, SymbolicConstant, SymbolicBinOp.