Skip the warning in gpytorch.lazy.__getattr__ if name starts with _

[saitcakmak]

The current setup leads to the unittest self.assertWarns... to wrongly trigger a warning when entering _AssertWarnsContext (calls getattr on all modules: /~https://github.com/python/cpython/blob/main/Lib/unittest/case.py#L292-L294). Filtering out based on name starting with _ eliminates the needless warning and keeps the correct behavior.

[esantorella]

Hm, this seems like a very roundabout way of preventing this warning from being raised in an _AssertWarnsContext. Could the check be changed from if not name.startswith("_") to if name != "__warningregistry__"? Failing that, it would be good to have a comment explaining why the underscore check exists.

Or maybe the warning should be somewhere else? Perhaps in deprecated_lazy_tensor or deprecated_lazy_tensor.__init__, so it's only raised when a LazyTensor is actually instantiated?

[saitcakmak]

I left this check intentionally general since there may be other uses of getattr that we are not aware of, leading to the same warning elsewhere.

Or maybe the warning should be somewhere else? Perhaps in deprecated_lazy_tensor or deprecated_lazy_tensor.init, so it's only raised when a LazyTensor is actually instantiated?

Yeah, that could work. It is a bit of a trade-off between raising the warning at import vs instantiation time. Assuming interactive development: import time warning says "don't use this thing" before you start using it; instantiation time warning says "go back and change this to the correct class", which is a bit more work.

These have been deprecated for over a year by now, so the right move might be to reap them altogether.

[Balandat]

These have been deprecated for over a year by now, so the right move might be to reap them altogether.

It'd be nice to get rid of the lazies and this special handling - cc @gpleiss

[saitcakmak]

Should we land this and follow up with full deprecation later?

[gpleiss]

Oops sorry for the slow reply. I think it makes sense to land this, and then we can go with full deprecation later.

In general, we should do a deprecation sweep and actually get rid of all of the things marked as deprecated. I think everything marked has deprecated has been deprecated for over a year at least.