From other thread:

On Wed, Feb 17, 2021 at 5:19 AM Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze <srkunze@mail.de> wrote:
> Still think that "object()" should be writable since this seems like an
> arbitrary restriction (+SimpleNamespace is no builtin and at least I
> would use object() for fast PoCs or dirty hackery). But I guess there's
> been discussion around this already.
>

It can't, because subclasses of object would then ALSO be writable,
and that would break a lot of things. Also, a lot of use-cases for
object() just need sentinels, with no attributes, so this would cost
them a lot of efficiency.

Using SimpleNamespace is the best way to do this, and maybe there's a
good argument for making it a builtin (or at least giving it a shorter
name), but changing object would be problematic.

ChrisA

I would personally love for SimpleNamespace to get a shorter name and become a built-in. It is a fantastic object to use in all kinds of situations and if it were given the same status as dict, tuple, etc etc, many more people would benefit from it. Right now it is pretty obscure and you could use python for years and not know about it. I think all but the most casual of python users at least end up on the built-in webpage at least once, clicking through to read about the different built-ins and what they are for.

Rick.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler


On Wed, Feb 17, 2021 at 9:46 AM Sven R. Kunze <srkunze@mail.de> wrote:
Starting this as a new thread for the interested reader:

On 17.02.21 11:18, Chris Angelico wrote:
> On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze <srkunze@mail.de> wrote:
>> Still think that "object()" should be writable since this seems like an
>> arbitrary restriction (+SimpleNamespace is no builtin and at least I
>> would use object() for fast PoCs or dirty hackery). But I guess there's
>> been discussion around this already.
>>
[...]

> Using SimpleNamespace is the best way to do this, and maybe there's a
> good argument for making it a builtin (or at least giving it a shorter
> name), but changing object would be problematic.

I would be skeptical that either those ideas would help a lot. My
reasoning is the following:


Given the usual terminology in computer science and programming courses,
we think in "objects". "Namespaces" on the other side are quite static,
usual representing surroundings or environments which in turn can
contain "objects". Sadly, the terminology-wise ideal solution is blocked
by technical reasons.


The thinking in the concepting use-case goes like "I need a blank object
which I can do random things with" (yes, including attaching new
attributes to it, maybe other stuff as well).

The thinking "hey I need a (simple) namespace which I can attach
attributes to" requires quite some thoughts especially when being in a
more "concepting"/"trying out ideas" mood.

In this phase, one does not simply know what one needs ("could be
sentinel only", "could be data carrying", "could be signalling", "could
something else") and things move quickly.


So, just as an example when renaming/aliasing "types.SimpleNamespace" to
"builtins.thing", my expectation would be that people could be horribly
confused seeing "object" and "thing" being a builtin when used in a
project simultaneously. This always leads to questions like "what to use
now?"


As a conclusion I would say let's leave it like it is since it's a minor
issue.


Best
Sven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/3IICAAKFYPL7JETS26CHPUVRVQS7KW3Y/
Code of Conduct: http://python.org/psf/codeofconduct/