How can I make an alias to a non-function member attribute in a Python class?

You can provide a __setattr__ and __getattr__ that reference an aliases map:

class Dummy:
    aliases = {
        'xValue': 'x',
        'another': 'x',
    }

    def __init__(self):
        self.x = 17

    def __setattr__(self, name, value):
        name = self.aliases.get(name, name)
        object.__setattr__(self, name, value)

    def __getattr__(self, name):
        if name == "aliases":
            raise AttributeError  # http://nedbatchelder.com/blog/201010/surprising_getattr_recursion.html
        name = self.aliases.get(name, name)
        return object.__getattribute__(self, name)


d = Dummy()
assert d.x == 17
assert d.xValue == 17
d.x = 23
assert d.xValue == 23
d.xValue = 1492
assert d.x == 1492

What are you going to do when half your users decide to use d.x and the other half d.xValue? What happens when they try to share code? Sure, it will work, if you know all the aliases, but will it be obvious? Will it be obvious to you when you put away your code for a year?

In the end, I think this kind of niceness or luxury is an evil trap that will eventually cause more confusion than good.

---

It's mostly because my scripting API is used across multiple subsystems & domains, so the default vocabulary changes. What's known as "X" in one domain is known as "Y" in another domain.

You could make aliases with properties this way:

class Dummy(object):
   def __init__(self):
      self.x=1
   @property
   def xValue(self):
      return self.x
   @xValue.setter
   def xValue(self,value):
      self.x=value

d=Dummy()
print(d.x)
# 1
d.xValue=2
print(d.x)
# 2

But for the reasons mentioned above, I don't think this is a good design. It makes Dummy harder to read, understand and use. For each user you've doubled the size of the API the user must know in order to understand Dummy.

A better alternative is to use the Adapter design pattern. This allows you to keep Dummy nice, compact, succinct:

class Dummy(object):
   def __init__(self):
      self.x=1

While those users in the subdomain who wish to use a different vocabulary can do so by using an Adaptor class:

class DummyAdaptor(object):
   def __init__(self):
      self.dummy=Dummy()
   @property
   def xValue(self):
      return self.dummy.x
   @xValue.setter
   def xValue(self,value):
      self.dummy.x=value    

For each method and attribute in Dummy, you simply hook up similar methods and properties which delegate the heavy lifting to an instance of Dummy.

It might be more lines of code, but it will allow you to preserve a clean design for Dummy, easier to maintain, document, and unit test. People will write code that makes sense because the class will restrict what API is available, and there will be only one name for each concept given the class they've chosen.

This can be solved in exactly the same way as with class methods. For example:

class Dummy:
    def __init__(self):
        self._x = 17

    @property
    def x(self):
        return self._x

    @x.setter
    def x(self, inp):
        self._x = inp

    @x.deleter
    def x(self):
        del self._x

    # Alias
    xValue = x

d = Dummy()
print(d.x, d.xValue)
#=> (17, 17)
d.x = 0
print(d.x, d.xValue)
#=> (0, 0)
d.xValue = 100
print(d.x, d.xValue)
#=> (100, 100)

The two values will always stay in sync. You write the actual property code with the attribute name you prefer, and then you alias it with whatever legacy name(s) you need.