[Python-ideas] Proposal to add new built-in struct (was: Add kwargs to built-in function object)

[Brandon Mintern]

On Thu, May 22, 2008 at 7:00 PM, Brett Cannon <brett at python.org> wrote:
>> If foo["bar"] is not cumbersome, it is at least less elegant and the
>> intent is less clear than foo.bar. Moreover, as I stated in the next
>> paragraph, it does become cumbersome down the line when you decide
>> that you should have used a class after all, and now you have to
>> change all of those foo["bar"] lines to foo.bar. Note that simple
>> search-and-replace wouldn't help if you are passing foo to various
>> functions.
>>
>
> But you are suggesting that people think far enough ahead to think
> that a sequence or mapping will be cumbersome and thus something with
> attribute access should be used instead.

Perhaps a lot of people wouldn't, unless the tutorial reflected the
idea of using struct for anonymous, structured data. When I started
out, I initially settled on tuples because it was the easiest to build
up front, and I didn't see any better alternatives. After the
frustration of maintaining tuple-based structures, I began to use
dicts instead, but I didn't like the syntax all that much, and it
looks weird (in my opinion) to have code that declares and indexes a
dictionary when what you really want is something like a C struct.

I guess what I'm suggesting is that if a clear solution is presented
that fits the use case well, I would expect a nontrivial number of
people to use it. They would not be required to notice that it is then
easy to convert to a real class, because good practice is "enforced"
by the use of struct.

>>> Thinking of a name for your class is not difficult, especially if you
>>> keep it private to the module, class, function, etc.
>>
>> It may not be difficult, but when the name is unnecessary, simply
>> needing to declare it seems silly.
>>
>
> Well, we almost ditched lambda and were going to require people to
> define a simple function to replace lambda functions, so not everyone
> thinks it is silly.

I'm sorry to keep hammering on this issue, but anonymous functions
already have standard names from Math: f, g, h, fn, func, etc. In
other words,

def f (x, y): return x+y
f

is not much harder than

lambda x,y: x+y

(except for the fact that it cannot be used as an expression, which is
why I personally still like lambda).

With class names, there is no such convention. Therefore, something like

c = NamedTuple("C", "one two")
a = c(1, 2)

seems a bit strange. Why "c" and "C"? Why anything? Why should I have
to include "C" as an argument only to never use it? I think that

a = struct(one=1, two=2)

clearly beats out the NamedTuple solution if all you really need is a struct.

>>> This does not strike me as useful enough to have as a built-in. It
>>> would be better placed in the stdlib.
>>
>> I would be happy with it at least becoming part of collections or some
>> other module, but then I wonder how many new-ish Python programmers
>> would persist in using a tuple or a dict instead of a more elegant
>> struct solution for lack of knowing about it. At least if it was in
>> Python somewhere, though, searching for "python struct" would be more
>> likely to return what the programmer is looking for.
>>
>
> Sticking something in built-ins so that it is easier for newbies to
> find it is not a good argument. Things only go into builtins if they
> are frequently used and warrant skipping an import statement.

Fair enough. It would make sense to initially put it into collections,
make sure people know about it, and then see how often it's used.

>> Ouch... it seems that struct is already the name of a module. If
>> enough people like my idea, perhaps that module could be renamed to
>> "cstruct". Then again, if my idea did become a part of collections
>> (rather than a built-in), collections.struct and the struct module
>> would be able to co-exist, albeit somewhat confusingly.
>>
>
> I don't agree with that worry. re.compile() exists and people don't
> worry about conflicting with the built-in function. An import
> statement makes it clear what object 'struct' maps to in the
> namespace.

Good, because I much-prefer using the name "struct" since it maps so
closely to a C struct.

Brandon