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 firstname.lastname@example.org wrote:
On Wed, Sep 17, 2014 at 01:51:29AM -0700, Andrew Barnert wrote:
On Sep 16, 2014, at 23:21, David Mertz email@example.com 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 a.py containing functions f and g, f can call g:
def f(): return g()
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
@namespace class stuff:
*looks* like a class even though it isn't, but it will do as a proof-of-concept.
-- Steven _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/