On Thu, May 22, 2008 at 7:00 PM, Brett Cannon firstname.lastname@example.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.