Class definition within a function or another class

Question

I’ve seen in some scripts definitions of classes within other classes or functions like this:

class Grok(object):

    class Foo(object):
        ...

    ...

What is the reason for this practice? It is only to not allow the direct instantiation of the class defined internally, and this is really a good practice or should I avoid its use at any cost ?

class Circle:
        class DrawingAPIOne:
                '''Implementation-specific abstraction'''
                def drawCircle(self, x, y, radius):
                        print("API 1 is drawing a circle at ({}, {}) with radius {}".format(x, y, radius))
        class DrawingAPITwo:
                '''Implementation-specific abstraction'''
                def drawCircle(self, x, y, radius):
                        print("API 2 is drawing a circle at ({}, {}) with radius {}".format(x, y, radius))

        def __init__(self, x, y, radius):
                '''Implementation-independent abstraction; Initialize the necessary attributes'''
                self._x = x
                self._y = y
                self._radius = radius
        def drawWithAPIOne(self):
                '''Implementation-specific abstraction'''
                objectOfAPIone = self.DrawingAPIOne()
                objectOfAPIone.drawCircle(self._x, self._y, self._radius)
        def drawWithAPITwo(self):
                '''Implementation-specific abstraction'''
                objectOfAPItwo = self.DrawingAPITwo()
                objectOfAPItwo.drawCircle(self._x, self._y, self._radius)
        def scale(self, percent):
                '''Implementation-independent abstraction'''
                self._radius *= percent

I saw this code on the website: https://www.djangospin.com/design-patterns-python/bridge/

Answer 1

Generally, the smaller the scope of something, the less it pollutes the code, the more it becomes encapsulated and protected from misuse and generates fewer external concerns. Everything that is public has to be more careful, not only with it itself, but anything that you create needs to be done in a way that doesn’t conflict with what exists. In general scope this becomes very complicated.

However Python does not work with class scope in the way other languages do. From what I understand has even conflicting PEP on the subject. So the protection does not happen. What makes some (little) sense, after all Python has always been a language of script, more recently it has tried to stop being and then the best defined and protected scope becomes more important.

That’s why most of the time that creating a class within such a small scope in a language without ceremony like Python is probably following good practice the way it’s worse, not knowing why, without having a real reason to use it like this, You only do it because you saw someone do it. And guess what? Many codes you see this way is because the person just "followed good practice" without knowing why, without identifying if the context required so. Usually not good to use.

And beware of abstract examples, they usually show a mechanism, not how to do in production.

This is an example that has how to solve otherwise using lambda, for example. Actually in written form even needs this abstraction.