AttributeError: 'xxx' object has no attribute 'tng_dataloader' continued...
This is the same issue as mentioned in #125.
Describe the bug
Whenever a @property raises an AttributeError, it will be looked up in __getattr__ (if defined), and then the original error message is lost. And LightingModule inherits __getattr__ from torch.nn.Module.
This makes debugging difficult as you lose line number and you get an error message that is misleading - the attribute exists! Look at the minimal example in the next section to see what I mean.
To Reproduce
import torch

class Foo(torch.nn.Module):
    @property
    def bar(self):
        return torch.does_not_exist  # Raises an AttributeError.

Foo().bar

The output produced:
Traceback (most recent call last):
  File "C:/minimal.py", line 8, in <module>
    Foo().bar
  File "C:\Program Files\Python37\lib\site-packages\torch\nn\modules\module.py", line 591, in __getattr__
    type(self).__name__, name))
AttributeError: 'Foo' object has no attribute 'bar'

The trace says the bar attribute does not exist, but it does. It is the does_not_exist attribute that is nonexistent. Now if you look in the stack trace in #125 it is even worse.
Expected behavior
One would expect the stack trace to be
Traceback (most recent call last):
  File "C:/minimal.py", line 7, in bar
    return torch.does_not_exist  # Raises an AttributeError.
AttributeError: module 'torch' has no attribute 'does_not_exist'

I think it could be very useful to add try...catch to the pl.data_loader.
One could also make a pl.attribute decorator that users (and pl.data_loader) can use, and document its use case in the docs. It should simply extend the usual @attribute with a try...catch.
An example of a more desirable stack trace
Traceback (most recent call last):
  File "C:/minimal.py", line 7, in bar
    return torch.does_not_exist  # Raises an AttributeError.
AttributeError: module 'torch' has no attribute 'does_not_exist'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:/minimal.py", line 11, in <module>
    Foo().bar
  File "C:/minimal.py", line 9, in bar
    raise RuntimeError('An AttributeError was encountered in Foo.bar.') from e
RuntimeError: An AttributeError was encountered in Foo.bar.

In this case the error is correctly shown to be at line 7.
This stack trace is achieved by replacing line 7 with:
try:
    return torch.does_not_exist  # Raises an AttributeError.
except AttributeError as e:
    raise RuntimeError('An AttributeError was encountered in Foo.bar.') from e

Additional context
See also the discussion in pytorch/pytorch#13981 of the problem. It seems to be a troublesome design decision of the language that will be hard to get around.
Do you think @pl.attribute is a good idea?
There seem to be no other way around the issue if we must use nn.Module and @attribute.