Create custom setattr for most python objects

[MicahGale]

Description

Python is wonderfully terrible that methods, and variables can added on the fly. This makes it less like java, but means that typos can go undetected by python. For instance model.goemetry = new_geom would be totally fine, but can and does cause user frustration with debugging. So I propose we somehow enforce the allowed variables for some subset of classes in the python api so that the above example would raise AttributeError.

There a few ways to go about this that I've discussed before for MontePy.

The most "traditional" approach is to switch from __dict__ to __slots__. I won't get into the nuance as I'm not an expert. The key points are:

1. This would accomplish the goal
2. You have to explicitly list all variables for the classes you want to do this with.

This would something like:

class Model:
    __slots__ = ("geometry", ...)

Or so it would seem. However, methods get automatically added, so @property doesn't need to be added, just hidden ones. So this would actually be more like:

class Model:
    __slots__ = ("_geometry", ...)
 
   @property
   def geometry(self):
      pass

The other option is to override __setattr__ and do some enforcement. Something like:

def __setattr__(self, key, value):
    try:
      self.key
      self.__dict__[key] = value
    except AttributeError as e:
       raise AttributeError(f"Es ist verboden! ...") from e

This latter option would require less code, they it doesn't feel as clean. It isn't not pythonic though, I think.

Compatibility

The biggest issue I see is some users may view this as a feature and not a bug, and like to add random attributes to their openmc model. In that case we could an option to change these errors into Warnings.

[MicahGale]

A little more research: In python 3.10 NameError and AttributeError is super helpful now a days, and can sometimes give hints for typos: NameError: name 'FuelSheers' is not defined. Did you mean: 'FuelShears'?

I suspect this is because NameError and AttributeError had new keyword arguments added in 3.10. I suspect this is the mechanism to allow this. I haven't been able to replicate this behavior in ipython yet effectively. I did find the bug report that added this feature though: https://bugs.python.org/issue38530, python/cpython#25397.

In my experimentation the name argument in the constructor is either used or ignored in both python 3.7 or 3.10, without causing additional errors, so python version specific implementations are not needed.

The final aspect that needs research is: how to trigger the typo suggestions.

[MicahGale]

Looking into it further, it seems like it might be easiest to just let python handle everything on its own: so I am thinking just force an attributeError to occur first:

# TODO figure out a better system for this
OPENMC_FULL_INIT = False

class Base:
   def __setattr__(self, attr, val):
        # avoid issues during MetaClass creation
       if OPENMC_FULL_INIT and not attr.startswith("_"): 
           # force a getattr
           try: 
              getattr(self, attr)
           except AttributeError as e:
              # TODO spruce up the stack trace and clarify the error
              pass
          # not sure if super is needed here
          super().__setattr__(self, attr, val)

Sorry for the stream of consciousness. How does this sound @tjlaboss?

[MicahGale]

Final thought for today: raising AttributeError on setattr isn't very pythonic, so I'm wondering if the exception should be downgraded to a Warning. That way the user can decide how they want to handle this. I see a user doing one of three things:

1. realize there's a mistake and correct it: (~90% of cases by my guess).
2. Know what they are doing with custom attributes and just ignore the warnings.
3. Know what they are doing and suppress the warnings.

This brings up the question: is AttributeError a specific enough class to allow proper Warning filters, or should it be subclassed? I am thinking that it is specific enough as I don't think many other libraries will have this behavior.