Hacker News Reader

Comment by coldtea | Hacker News Reader

>It seems like the python maintainers always try to complicate things for themselves to cater for some obscure use case that nobody use. I mean really, when was the last time you ever accessed a namedtuple by index??

Notice how when someone asks something like that, some bizarro practitioners of such methods would always appear and say how they are invaluable for them...

View on HN

It's called a tuple so why would accessing its elements by index be "bizarre" in any way?

Because the whole point of namedtuples is to have them as a convenient quick notation for records.

But I was referring to the parent's general observation that about "catering to some obscure use case that nobody uses", which I agree with -- not about their specific example.

Because order should be unimportant for a tuple.

Order is important for "pure" Python tuples, so I see no reason why it shouldn't be the case for namedtuple. Mathematical tuples are ordered as well:

"In mathematics a tuple is a finite ordered list (sequence) of elements. An n-tuple is a sequence (or ordered list) of n elements, where n is a non-negative integer. There is only one 0-tuple, an empty sequence. An n-tuple is defined inductively using the construction of an ordered pair." (Wikipedia)

Followup:

Should order be important for a Tuple under a system that defines a Tuple as an immutable ordering?

That is, whatever your philosophical issues with namedtuple ordering, in python, a tuple is an immutable ordered list of things. In practice, tuples have taken the role of being type-heterogenous, known length, records.

One might then reasonably expect a namedtuple to be a type-heterogneous, known length, record, where attributes are named.

Tuples are ordered by definition. We use names for things to convey what they are, not what we want them to be. If you want a construct in which order does not matter, call it a set or a dict.

Are you joking or serious? I can't read your tone without emoji.

Serious; see coldtea's reply for a fuller explanation.

Or consider (firstname="John", lastname="Doe") vs (lastname="Doe", firstname="John").

I think you'd agree that they're the same.

They are the "same" by equality, but that's not the only relevant comparison. Ordering is important if you want lexicographic less than.

Without ordering, you wouldn't be able to sanely run `sorted` on a iterable of namedtuples.

Dumb question from a non-developer: wouldn't using a dict object make more sense if someone wanted an unordered named tuple?

It's not about the storage (besides Python also has order dicts).

Namedtuples are for the convenience of creating a record type (though indeed as others say, treating it as tuple where things expect a tuple is also a benefit).

A dict is appropriate for labeled data. Currently unordered, but likely to keep insertion order in v3.7 and later.

Don't call it an unordered namedtuple. That's confusing, because tuples are ordered.

You could order with a custom comparison; specify the columns* to be ordered as in a SQL 'ORDER BY'.

I would expect that construction to result in identical behavior for dict() and certainly not anything calling itself a tuple. NamedTuples behaving in the manner you expect violates LSP with respect to tuple().

I disagree. As of v3.6, the order of keyword arguments is preserved.

Typically tuples are ordered lists of values. See Codd's relational model, Linda, Erlang, etc.

In the relational model the order shouldn't matter:

  A relation is defined as a set of n-tuples. In both mathematics and the 
  relational database model, a set is an unordered collection of unique, non-
  duplicated items, although some DBMSs impose an order to their data. In 
  mathematics, a tuple has an order, and allows for duplication. E. F. Codd 
  originally defined tuples using this mathematical definition. 

  Later, it was one of E. F. Codd's great insights that using attribute names 
  instead of an  ordering would be so much more convenient (in general) in a 
  computer language based on relations. This insight is still being used today. 
  Though the concept has changed, the name "tuple" has not.

I stand corrected; I was probably fooled by the naming. Still, in most contexts tuples are ordered while sets/bags are not.

FWIW I was referring to the abstract pure tuple, not the tuple as implemented in Python and some other languages where order is very useful.

"inessential" might be a better than "unimportant"

It's invaluable in several use cases, especially when working with external code that expects a tuple, when unpacking a tuple (a, b = c) especially when iterating over them in a loop (for a, b in c).

You have used some of these methods before. So are you bizzaro?

No. Nobody is bizarro for mentioning this, it's extremely handy and it's kind of in the name: namedtuple. Without this they are utterly pointless.

I'm flattered :)

Although I can't tell if the moral of this is "if the api allows, it will be done, and you can't break the api later", or if the moral is "just because you think it's useless doesn't mean it really is".

some bizarro practitioners

That would be the bizarro practitioners who expect subclassing to actually be subclassing. Maybe there is a sane argument that namedtuple shouldn't be a subclass of tuple but that ship sailed a long time ago.

Yes, it should be a special construct (record).

Python has really painted themselves into a corner. The language is so extremely dynamic with everything being allowed and people actually relying on such things that you can't even look at the language without breaking backwards compatibility. https://xkcd.com/1172/ is a very accurate description of the current state.

Python has painted itself into the top position on the most popular list,and has been in the top three for as long as I can remember, mostly because of its inherent internal dynamism. People relying on decades old language features is the opposite of a problem.

https://www.extremetech.com/computing/252987-python-tops-lis...

People use python because it has nice syntax, batteries included standard library, easy to make code for both windows and Linux, no compilation, big community, and it's the closest arm to reach out to when you realise your shell scripts are getting too big.

Not because you can monkeypatch the _attrs_ function on the fly somewhere on a class in the standard library.

Reply on news.ycombinator.com