On Mon, Jul 29, 2019 at 05:58:02PM -0400, Ricky Teachey wrote: > I agree. This is why my preferred solution would be more something like I > proposed, such as: > > def my_namespace: > a = 1 > def f(x): ...
This has the advantages of: 1. Avoiding the need to repeat the name twice. 2. Avoiding the need for a new keyword but two serious disadvantages: 1. It is currently illegal syntax, so it doesn't work without compiler support. That means we can't publish it as a module on PyPy, can't backport it to older versions, and you have to convince the core-devs that both the feature itself and the syntax are worth building into the language. 2. It looks like a function. That means that these two very similar looking defs do *radically* different things: def spam(): # creates a FUNCTION and binds to name "spam" def spam: # creates a NAMESPACE and binds to name "spam" That will lead to a lot of accidental "why is my namespace/function not working?" problems. As a prototype, it might be possible to wrap the machinary to create a namespace in a function call, but as permanant language syntax, it isn't a good idea. > etc etc. > > I also do not see any benefit in being able to provide some arbitrary > string as the module/namespace name, as others have proposed: > > with Namespace('ns') as ns: ... It's not ideal because we are repeating ourselves, but if its good enough for namedtuples, its good enough for namespaces. If the core developers don't consider namedtuples important enough to get syntactic support, I doubt that namespaces will. If namespace objects are considered a kind of module or module-like object, they need a name for the repr and for introspection, and they need to be bound to a name (a variable). The name binding is automatically handled by the with-statement, but how else are you going to inform the namespace object of its internal name? > Modules are already named by the file name they reside in. Functions > (also defined using "def") are named using the name given to the > function. Same with a class. This doesn't "just happen", but because the interpreter does the work of extracting the name and feeding it to the constructors, which have these signatures: ModuleType(name[, doc]) FunctionType(code, globals[, name[, argdefs[, closure]]]) type(name, bases, dict) # Creates a new class. > Creating a namespace/module type thing > that receives its name as some argument would seem, to me, to be > orthogonal to these other situations. How else are you going to inform the namespace object what name it should use internally, without interpreter support? -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UWXWJ677LH2NUCL3RFLCITUJ6DAP5QMF/ Code of Conduct: http://python.org/psf/codeofconduct/