Using namedtuples field names for column indices in a list of lists

Deborah Swanson python at
Wed Jan 11 17:57:24 EST 2017

Steven D'Aprano wrote, on January 10, 2017 6:19 PM
> On Tuesday 10 January 2017 18:14, Deborah Swanson wrote:
> > I'm guessing that you (and those who see things like you do) might 
> > not be used to working with quick learners who make mistakes at 
> > first but catch up with them real fast, or you're very judgemental 
> > about people who make mistakes, period. I certainly don't care if 
> > you want to judge me, you're entitled to your opinion.
> Be fair. We're not mind-readers, and we're trying to help you, not 
> attack you.

You aren't, and I've never seen you as attacking me, but there's a few
others here who have attacked me, and they weren't trying to help me
either. But it's only a very few people who've harrassed me, and the
person I was writing to above wasn't one of them. 

> It is true that we're often extremely pedantic. Sometimes annoyingly
> so, but on the other hand precision is important, especially in 
> technical fields. > There's a *huge* difference between a MTA and a 
> MUA, even though they differ only by one letter and both are related 
> to email.
> One of the techs I work with has the same habit of correcting me, and 
> when I'm invariably forced to agree that he is technical correct, he 
> replies "technical correctness is the best kind of correctness". 
> Annoying as it is to be on the receiving end, he is right: at least 
> half the time I learn something from his pedantry. (The other half of 
> the time, its a difference that makes no difference.)

I'm sorry you have to work with someone like that, he sounds perfectly
awful. (But that doesn't give you license to do the same. You're better
than that.)

> What are we supposed to do when somebody asks a question based on an
> obvious mistake? Assume that they're a quick learner who has probably 
> already worked out their mistake and doesn't need an answer? That 
> would certainly make our life easier: we can just ignore everybody's 
> questions.

No, of course not. My advice to people who want to help is to not assume
that you know what the question asker does and doesn't know, and just
answer the questions without obsessing about what they know. If that's
impossible because they have something so wrong that you don't know what
they're asking, that would be a good time to point it out and give them
a chance to correct it. 

> Sometimes people make errors of terminology that doesn't affect the 
> semantics of what they're asking:
>     "I have an array [1, 2, 3, 4] and I want to ..."
> It's very likely that they have a list and they're merely using a term

> they're familiar with from another language, rather than the array 
> module.
> But what are we supposed to make of mistakes that *do* affect the 
> semantics of the question:
>     "I have a dict of ints {1, 2, 3, 4} and want to sort the values by

>     key so that I get [4, 2, 3, 1], how do I do that?"
> How can we answer that without correcting their misuse of terminology
> and asking for clarification of what data structure they *actually* 
> have?
> We get questions like this very frequently. How would you answer it?

Well, I'd tell them how to reverse sort a dictionary, and point out that
what they've given isn't a dictionary because it doesn't have any keys,
and on this occasion I'd just give them an example of what a dictionary
looks like (as part of showing them how to reverse sort it) with its
keys, including the curly braces, and see what they come back with. They
pretty clearly mean a dictionary and not a list, since they said "dict",
used curly braces, and said they want to sort the values by key" in the
first clause of their sentence. So they're just a little confused and
maybe absent-mindedly slipping back into the more familiar list notation
and concepts, or they don't exactly know what a dictionary is. I
wouldn't belabor the point at this time, unless they keep coming back
with the same issues. That would be the time to belabor it, in my
opinion.  When some people are learning it's hard to keep all the new
things firmly in mind and not confuse them with more familiar things
they already know. But if they get it all straight in reasonably good
time, that should be ok. 

> Or:
>     "I have a list l = namedtuple('l', 'field1 field2') and can't 
>     extract fields by index, l[0] doesn't work..."
> Of course it doesn't work. How would you respond to that if you were
> in our place?
> - ignore the question because the poster is ever so smart and will
>   worked it out by now?
> - point out that l is not a list, or even a tuple, and of course l[0] 
>   doesn't work because l is actually a class?

I'd go with some variant of option 2, depending on how well I knew the
person asking. If the asker had just dropped in out of the blue and I
knew nothing about them I'd say something like "You can't because 'l'
isn't a list." Then I'd try to gauge how useful it would be to them to
know exactly what 'l' is, but most likely I would be asking them one of
several questions next (depending on the context), because it's not
clear what they're trying to do. You can't proceed if you don't have
enough information to work with. (Well, you can, but it frequently
doesn't work out too well.)
> Its easy to criticise us for answering the questions you ask instead
> of the questions you intended, but we're not mind-readers. We don't 
> know what you're thinking, we only know what you communicate to us. 
> Telling us off for answering your questions is hardly likely to 
> encourage us to answer them in the future.
> --
> Steven
> "Ever since I learned about confirmation bias, I've been seeing it 
> everywhere." - Jon Ronson

I imagine that people answer questions because they're interested in the
question, or they want to help. But really, it's up to them whether they
want to answer it or not.

More information about the Python-list mailing list