Pogo pytango HL - allocate read data member for attribute allocates a dunder variable instead of a single underscore

# 1 month ago
VigneshV	Pogo version - 9.8.3 Dear Developers, When I set checked the option "Allocate - read data member" in pogo, a double underscore variable is created in python. For example - an attribute Attribute1 will have a member self.__atribute1 created in init_device. This is not a problem if there is no inheritance. However, as you know, in python, due to name mangling, double underscore variables create problem during inheritance when the attribute was created in a parent class, being read in parent class, but is being assigned in the child class. Unfortunately unchecking "Allocate - read data member" has no effect and the double underscore is still created in init device. Currently, I just delete these double underscores and create my own single underscore attributes in init_device. But if pogo can generate single underscore or unchecking the read data member works, that would be best. Please let me know if this was already addressed.

# 1 month ago

Pogo version - 9.8.3

Dear Developers,

When I set checked the option "Allocate - read data member" in pogo, a double underscore variable is created in python. For example - an attribute Attribute1 will have a member self.__atribute1 created in init_device.

This is not a problem if there is no inheritance. However, as you know, in python, due to name mangling, double underscore variables create problem during inheritance when the attribute was created in a parent class, being read in parent class, but is being assigned in the child class.

Unfortunately unchecking "Allocate - read data member" has no effect and the double underscore is still created in init device.

Currently, I just delete these double underscores and create my own single underscore attributes in init_device. But if pogo can generate single underscore or unchecking the read data member works, that would be best.

Please let me know if this was already addressed.

# 4 weeks ago
Damien Lacoste	Hi, As far as I know this issue is not addressed. It should be fixable, the question is how. First the "Allocate - read data member" is not supposed to do anything when generating python code, it's only used for C++ code generation, so it's the expected behavior that it doesn't change anything. But then if you were expecting something different I'd like to understand why, and what you would expect. On fixing the issue itself, replacing the double underscore by a single one seems to be the way to go, it can be done but it may lead to other issues. Backward compatibility, people who generated code with the double underscore will have to change potentially a lot of things in their code if we change this. And I don't know it, but there might be a good reason why people chose to put a double underscore there… So we need to discuss a bit this issue, see if it doesn't cause more trouble to fix it, and then we'll get to it! Cheers, and sorry for the delay…

# 4 weeks ago

Damien Lacoste

Hi,

As far as I know this issue is not addressed. It should be fixable, the question is how.

First the "Allocate - read data member" is not supposed to do anything when generating python code, it's only used for C++ code generation, so it's the expected behavior that it doesn't change anything. But then if you were expecting something different I'd like to understand why, and what you would expect.

On fixing the issue itself, replacing the double underscore by a single one seems to be the way to go, it can be done but it may lead to other issues.
Backward compatibility, people who generated code with the double underscore will have to change potentially a lot of things in their code if we change this.
And I don't know it, but there might be a good reason why people chose to put a double underscore there…

So we need to discuss a bit this issue, see if it doesn't cause more trouble to fix it, and then we'll get to it!

Cheers, and sorry for the delay…

# 4 weeks ago
VigneshV	Alright, I dont have a concrete idea on what to expect but the reasoning was that when the read_{attribute name} method is called, we generally return this autogenerated variable. This this autogenerated variable is the "allocated read data member". However if there is a different definition originating from CPP level, then this is not useful. Regarding the fix, sure, I just want to report it as a potential improvement of pogo.

# 4 weeks ago

VigneshV

Alright, I dont have a concrete idea on what to expect but the reasoning was that when the read_{attribute name} method is called, we generally return this autogenerated variable. This this autogenerated variable is the "allocated read data member".

However if there is a different definition originating from CPP level, then this is not useful.

Regarding the fix, sure, I just want to report it as a potential improvement of pogo.

# 3 weeks ago
Damien Lacoste	This is actually a bug… I created an issue: https://gitlab.com/tango-controls/pogo/-/issues/165 so for a workaround, rename your attribute from Attribute1 to attribute1 and you should be fine. I'm planning to make some releases for pogo soonish, so expect a fix in the coming couple of months. Cheers