Instantiating an abstract model with a string ForeignKey fails with TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types

[Jonas Trappenberg]

Trying to instantiate an abstract model with a foreign key worked without throwing any warnings in Django 1.8. In Django 1.9.8, this code:

class UserProfile(Model):
    user = models.ForeignKey('auth.user')
    class Meta(object):
        app_label = 'core'
        abstract = True
UserProfile()

raises this exception:

Traceback (most recent call last):
  File "<ipython-input-7-5fa4dfdf1ad9>", line 2, in <module>
    UserProfile()
  File ".../.venv/lib/python2.7/site-packages/django/db/models/base.py", line 432, in __init__
    val = field.get_default()
  File ".../.venv/lib/python2.7/site-packages/django/db/models/fields/related.py", line 905, in get_default
    if isinstance(field_default, self.remote_field.model):
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types

While the code mentions that abstract models can not be instantiated [1], I couldn't find mention of this in the docs. Abstract models without foreign keys can still be instantiated perfectly fine.

I couldn't find any description of this change in the Release Notes, so not sure if I missed it there or if this is maybe an undocumented backwards-incompatible change.

[1] ​https://github.com/django/django/blob/026574e03c6b6fd20a45f97b0470afb70e41fda4/django/db/models/base.py#L284

[Tim Graham]

I'm not sure about the correct resolution, but I bisected the change to 9239f1dda7b94f53d21efb8b5e4d056e24f4e906 and am attaching a reproduction test case for Django's test suite.

[Simon Charette]

While it's not explicitly mentioned abstract models are not instantiable in the documentation there's a mention that ​such models are never meant to be used in isolation.

I would argue that even if it worked in Django < 1.8 it was undefined behavior and this breakage shouldn't be considered as a break of backward compatiblity. Even if we were to fix the get_default() case abstract models with lazily defined relationships (by passing model names instead of model classes) are now completely unusable as they're not resolved anymore.

Since the issue can be worked around by avoiding lazily defined relationships on abstract models and the reported use case was never meant to be supported I suggest we amend the documentation to be more explicit.

[Tim Graham]

How about raising a helpful message saying that abstract models can't be instantiated?

[Simon Charette]

Replying to timgraham:

How about raising a helpful message saying that abstract models can't be instantiated?

Raising a TypeError with an helpful message in Django 1.11+ could be useful but I don't think it should be backported at this point.

[Ien Cheng]

Wouldn't doing unit tests on a abstract model class be an appropriate use case for instantiating an abstract class? If not, what is the recommended approach to unit testing abstract model logic?

[Jacob Walls]

​PR

The documentation for Abstract base classes does mention that abstract models cannot be instantiated, but it comes in the discussion of the example CommonInfo. With the feedback provided by the TypeError raised in this PR, my initial thought is that this is sufficient documentation.

If folks want the prohibition on instantiation moved earlier, up above the example, it could be easily done.

[Jacob Walls]

Thinking more on this, if folks decide to add extra documentation or move documentation (that abstract models should not be instantiated) to a more discoverable place, that is probably something to be considered for backport, if it's worth doing at all. In that case that would be a separate PR/ticket, no? The change in this PR won't be backported.

[Mariusz Felisiak]

It's stated in docs that abstract models cannot be instantiated, IMO there is no need for an extra clarification.

[Mariusz Felisiak <felisiak.mariusz@…>]

In c7e7f17:

Fixed #26977 -- Made abstract models raise TypeError when instantiating.