4 ms·

BDFL says: > Concluding, I think we should move on from the original implementation and optimize the heck out of namedtuple. I remember reading this on the ma

BDFL says: > Concluding, I think we should move on from the original implementation and optimize the heck out of namedtuple. I remember reading this on the mailing list and thinking "yes, namedtuple deserves optimization because it's an excellent resource". For my use cases, I don't think I notice Python's startup time. When I write Python code it's usually not performance critical. When I do write performance-critical Python code, I usually care about total runtime and PyPy is usually a win here. Aside: if you use PyPy, you should probably be using namedtuples. IIRC it models those much better than it does dicts. And IMO namedtuples model many common data structures better than dicts do. Just because I don't feel the pain of Python's startup time doesn't mean we shouldn't try to optimize it. I think I find my way into some esoteric Python/CPython corners but FWIW I've never needed namedtuple's "_source" attr.

mikepurvis 9y ago
Ruby's idea of a hash where the keys are colon symbols seems to really strike a sweet spot here— it's fast and storage-efficient like a tuple, but has the flexibility of a dict.
- sevensor 9y ago
  One big advantage of using namedtuples, aside from the immutability I mentioned elsewhere, is that you can rely on a namedtuple having particular fields. So if you're using dictionaries, you have to worry about KeyError wherever the dict is used, but if you're using namedtuples, you can't create them without assigning values to all of the fields. Dictionaries are still great for their intended purpose -- to represent a mapping -- but namedtuples are nicer if what you really want is a lightweight object.
  - mikepurvis 9y ago
    Setting default values for the namedtuple requires subclassing it, though, which is its own little bag of fun. See all the wailing and gnashing of teeth on SO: https://stackoverflow.com/search?q=namedtuple+subclass https://stackoverflow.com/search?q=namedtuple+subclass
    - sevensor 9y ago
      When this is an issue, I tend to create a namedtuple with default values for the fields at the same time I'm defining the namedtuple type itself. NT = namedtuple("NT", ('a', 'b')) default_NT = NT(42, 'foo') And then later, if I want to initialize only one field: my_new_NT = default_NT._replace(a=7)
      - mikepurvis 9y ago
        I guess that works, but it's a pretty big departure from the expected API of a normal namedtuple, or any other object-with-constructor, for that matter.
        sevensor 9y ago
        If you really want it to look more traditional, you could do: NT.new = lambda **kwargs: NT(42, 'foo')._replace(**kwargs) Now you can make NT objects like so: nt1 = NT.new() nt2 = NT.new(b='bar') You can call it something else if calling it "new" makes you feel weird. (I'd call it something else, but naming things is hard.)
    - JelleZijlstra 9y ago
      If you're using Python 3.6, it's a lot easier now. You can do: from typing import NamedTuple class Point(NamedTuple): x: float y: float = 0.0 and then Point(1.0).y == 0.0.
      - sevensor 9y ago
        That's quite nice!
- xapata 9y ago
  AFAIK, that wasn't Ruby's idea.

mikepurvis 9y ago

Ruby's idea of a hash where the keys are colon symbols seems to really strike a sweet spot here— it's fast and storage-efficient like a tuple, but has the flexibility of a dict.

sevensor 9y ago
One big advantage of using namedtuples, aside from the immutability I mentioned elsewhere, is that you can rely on a namedtuple having particular fields. So if you're using dictionaries, you have to worry about KeyError wherever the dict is used, but if you're using namedtuples, you can't create them without assigning values to all of the fields. Dictionaries are still great for their intended purpose -- to represent a mapping -- but namedtuples are nicer if what you really want is a lightweight object.
- mikepurvis 9y ago
  Setting default values for the namedtuple requires subclassing it, though, which is its own little bag of fun. See all the wailing and gnashing of teeth on SO: https://stackoverflow.com/search?q=namedtuple+subclass https://stackoverflow.com/search?q=namedtuple+subclass
  - sevensor 9y ago
    When this is an issue, I tend to create a namedtuple with default values for the fields at the same time I'm defining the namedtuple type itself. NT = namedtuple("NT", ('a', 'b')) default_NT = NT(42, 'foo') And then later, if I want to initialize only one field: my_new_NT = default_NT._replace(a=7)
    - mikepurvis 9y ago
      I guess that works, but it's a pretty big departure from the expected API of a normal namedtuple, or any other object-with-constructor, for that matter.
      - sevensor 9y ago
        If you really want it to look more traditional, you could do: NT.new = lambda **kwargs: NT(42, 'foo')._replace(**kwargs) Now you can make NT objects like so: nt1 = NT.new() nt2 = NT.new(b='bar') You can call it something else if calling it "new" makes you feel weird. (I'd call it something else, but naming things is hard.)
  - JelleZijlstra 9y ago
    If you're using Python 3.6, it's a lot easier now. You can do: from typing import NamedTuple class Point(NamedTuple): x: float y: float = 0.0 and then Point(1.0).y == 0.0.
    - sevensor 9y ago
      That's quite nice!
xapata 9y ago
AFAIK, that wasn't Ruby's idea.