Thanks to everyone for the replies! I read them all with interest.

The fundamental issue for me is that you shouldn't just co-opt functionality. The semantics of a class is clearly intended to be a class of objects -- and instantiatable thing which is a core part of OO design. Re-using it for named blocks really just seems like it would be massively confusing, particularly if one were to interleave the two.

I also take Steve's point about the ability for functions to refer to eachother without using the full namespace. That would be another useful effect.

Does anyone think this idea is worth developing further, or is it best left as an interesting discussion?

On 17 September 2014 19:21, Steven D'Aprano <> wrote:
On Wed, Sep 17, 2014 at 01:51:29AM -0700, Andrew Barnert wrote:
> On Sep 16, 2014, at 23:21, David Mertz <> wrote:
> > Why is this a misuse?
> Well, for one thing, you're relying on the fact that unbound methods
> are just plain functions, which was not true in 2.x and is still not
> described that way in the documentation. You're also ignoring the fact
> that the first parameter of a method should be self and the convention
> (enforced by the interpreter 2.x, although no longer in 3.x, and by
> various lint tools, and likely relied on by IDEs, etc.) that when
> calling an unbound method you pass an instance of the class (or a
> subclass) as the first argument.

While all this is true, one can work around it by declaring all your
methods @staticmethod. But it's worse than that.

By using a class, you imply inheritance and instantiation. Neither is
relevant to the basic "namespace" idea.

Furthermore, there's no point (in my opinion) in having this sort of
namespace unless functions inside a namespace can refer to each other
without caring about the name of the namespace they are in. Think of
modules. Given a module containing functions f and g, f can call g:

def f():
    return g()

without writing:

def f():
    return a.g()

Classes don't give you that, so they are not up to the job.

Modules, on the other hand, give us almost exactly what is needed here.
We can create module instances on the fly, and populate them. A class
decorator could accept a class and return a module instance, on the fly.
That would still be ugly, since

class stuff:

*looks* like a class even though it isn't, but it will do as a

Python-ideas mailing list
Code of Conduct:

Tennessee Leeuwenburg
"Don't believe everything you think"