[Python-ideas] a simple namespace type

[Calvin Spealman]

On Sat, May 26, 2012 at 7:33 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Sat, May 26, 2012 at 3:02 PM, Calvin Spealman <ironfroggy at gmail.com> wrote:
>> On Sat, May 26, 2012 at 2:53 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>>> Any further thoughts on this?  Unless anyone is strongly opposed, I'd
>>> like to push this forward.
>>
>> There is no good name for such a type. "Namespace" is a bad name, because
>> the term "namespace" is already a general term that describes a lot of things in
>> Python (and outside it) and shouldn't share a name with a specific
>> thing, this type.
>> That this specific type would also be within the more general namespace-concept
>> only makes that worse.
>>
>> So, what do you call it?
>
> Yeah, I've seen it called at least 10 different things.  I'm certainly
> open to whatever works best.  I've called it "namespace" because it is
> one of the two kinds of namespace in Python: mapping ([]-access) and
> object (dotted-access).  The builtin dict fills the one role and the
> builtin object type almost fills the other.  I guess
> "dotted_namespace" or "attribute_namespace" would work if "namespace"
> is too confusing.
>
>> Also, is this here because you don't like typing the square brackets and quotes? If
>> so, does it only save you three characters and is that worth the increase to the
>> language size?
>
> This is definitely the stick against which to measure!
>
> It boils down to this: for me dotted-access communicates a different,
> more stable sort of namespace than does []-access (a la dicts).

This is probably the best case I've heard for such a type. Intent expression
is important!

> Certainly it is less typing, but that isn't really a draw for me.
> Dotted access is a little easier to read, which is nice but not the
> big deal for me.  No, the big deal is the conceptual difference
> inherent to access via string vs. access via identifier.
>
> Though Python does not currently have a basic, dynamic,
> attribute-based namespace type, it's trivial to make one: "class
> Namespace: pass" or "type('Namespace', (), {})".  While this has been
> done countless times, it's so simple that no one has felt like it
> belonged in the language.  And I think that's fine, though it wouldn't
> hurt to have something a little more than that (see my original
> message).
>
> So if it's so easy, why bother adding it?  Well, "class Namespace:
> pass" is not so simple to do using the C API.  That's about it.  (I
> *do* think people would be glad to have a basic attribute-based
> namespace type in the langauge.
>
>> A final complaint against: would the existence of this fragment
>> python-learners education
>> to the point that they would defer learning and practicing to use
>> classes properly?
>
> This is an excellent point.  I suppose it depends on who was teaching,
> and how a new simple "namespace" type were exposed and documented.  It
> certainly is not a replacement for classes, which have much more
> machinery surrounding state/methods/class-ness.  If it made it harder
> to learn Python then it would definitely have to bring *a lot* to the
> table.
>
>> Sorry to complain, but someone needs to in python-ideas! ;-)
>
> Hey, I was more worried about the crickets I was hearing.  :)
>
> -eric

The best names I was able to get crowdsourced from #python this morning
are:

- record
- flexobject
- attrobject
- attrdict
- nameddict
- namedobject

and the absolute worst name:
- Object

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy