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/
