@Samus: Leaving aside the unnecessary parentheses,...
Steve · 2013-04-29T08:02:41.552000
@Samus: Leaving aside the unnecessary parentheses, consider for example a memoizing function that remembers its arguments (a, b, c) and caches the result to avoid duplicating expensive computations. The natural way to store previously-seen arguments is as a dict, keyed by the tuple of argument values.
The basis logic (and sorry for Blogger's horrendous code mangling, by the way) would look like:
stash = {} def f(a, b, c): if (a, b, c) in stash: return stash[a, b, c] else: # long expensive computation stash[a, b, c] = result return result
In case this too gets mangled the source is stored as as Memoizing function skeleton on Pastebin with permanent retention. [Note: there's even a mistake on Pastebin, where the final return statement is indented one level too many]. If you can think of a more natural way to do this I will be interested to hear it.
Once again, I make the point that this was not the issue I started out to discuss. So while it's interesting it should be regarded as a "rathole" tending towards derailing discussion of the point I was originally trying to make. Sure, you are interested in it, but why do you imagine I should be? Would silence have been an acceptable response?
I was really just asking whether it might be a good idea to have a standard library equivalent of the fairly well-known "bunch" pattern. I believe (though would be happy to be corrected) that namedtuple is currently the nearest we have.
For extra points the interested reader should demonstrate a memoizing function that also accepts keyword arguments.
@anonymous: that sounds reasonable. Thanks for the...
Steve · 2013-04-29T08:15:33.556000
@anonymous: that sounds reasonable. Thanks for the example.
The classic use-case which tests any guideline abo...
Andrew Dalke · 2013-04-29T09:51:47.722000
The classic use-case which tests any guideline about tuples is the class __bases__ attribute. It returns a tuple. Generally speaking, it needs to be an immutable ordered collection of class-like object, where the length can be different for different classes. Python's tuple() is a perfect fit for this, and no other container comes close.
This case breaks most tuple guidelines: There is no meaning to a position beyond its relative ordering. Iterating over the base classes does make sense for some cases, such as building an inheritance diagram. It's not used as a dictionary key. Its members are homogenous.
FWIW, my biggest gripe about using namedtuples as light-weight immutable classes is the lingering ability to use indexing. Namedtuples are great as a backwards-compatible transition from tuples to class-like objects, which was needed for os.stat() and time.gmtime(). But in my own code I want the ability to transition from a nametuple to a class, without worrying that users of my API might have been using the getitem interface that I didn't want to implement. While people might also use the _asdict and _replace methods, it's a big temptation in inner loops to use obj[1] instead of obj.green (as with an RGB color class) because index lookup in a namedtuple is twice as fast as property lookup.
And of course in Haskell they're called produc...
boothead · 2013-05-04T10:30:51.900000
And of course in Haskell they're called product types. So given a tuple of (A, B) you can think of it as a cross product of anything from the A's and the set of B's.
I believe I'd rather know how it behaved than ...
Steve · 2013-05-04T10:43:24.730000
I believe I'd rather know how it behaved than have to think of it like that. From the outside Haskell seems disciplined and difficult, but people I respect in the Python world speak highly of it. I tend to think of it as the bastard child of ML and LISP. Ignorance is Bliss.
@Andrew: Well, I believe we are largely in agreeme...
Steve · 2013-05-04T10:54:54.950000
@Andrew: Well, I believe we are largely in agreement, but there is the valid point that unpacking assignments to the elements is a (somewhat) desirable feature. Does unpacking assignment rely on __getitem__(), or does it use __next__() and the iteration protocol?
@Samus: Leaving aside the unnecessary parentheses,...
Steve · 2013-04-29T08:02:41.552000
@Samus: Leaving aside the unnecessary parentheses, consider for example a memoizing function that remembers its arguments (a, b, c) and caches the result to avoid duplicating expensive computations. The natural way to store previously-seen arguments is as a dict, keyed by the tuple of argument values.The basis logic (and sorry for Blogger's horrendous code mangling, by the way) would look like:
stash = {}
def f(a, b, c):
if (a, b, c) in stash:
return stash[a, b, c]
else:
# long expensive computation
stash[a, b, c] = result
return result
In case this too gets mangled the source is stored as as Memoizing function skeleton on Pastebin with permanent retention. [Note: there's even a mistake on Pastebin, where the final return statement is indented one level too many]. If you can think of a more natural way to do this I will be interested to hear it.
Once again, I make the point that this was not the issue I started out to discuss. So while it's interesting it should be regarded as a "rathole" tending towards derailing discussion of the point I was originally trying to make. Sure, you are interested in it, but why do you imagine I should be? Would silence have been an acceptable response?
I was really just asking whether it might be a good idea to have a standard library equivalent of the fairly well-known "bunch" pattern. I believe (though would be happy to be corrected) that namedtuple is currently the nearest we have.
For extra points the interested reader should demonstrate a memoizing function that also accepts keyword arguments.
@anonymous: that sounds reasonable. Thanks for the...
Steve · 2013-04-29T08:15:33.556000
@anonymous: that sounds reasonable. Thanks for the example.The classic use-case which tests any guideline abo...
Andrew Dalke · 2013-04-29T09:51:47.722000
The classic use-case which tests any guideline about tuples is the class __bases__ attribute. It returns a tuple. Generally speaking, it needs to be an immutable ordered collection of class-like object, where the length can be different for different classes. Python's tuple() is a perfect fit for this, and no other container comes close.This case breaks most tuple guidelines: There is no meaning to a position beyond its relative ordering. Iterating over the base classes does make sense for some cases, such as building an inheritance diagram. It's not used as a dictionary key. Its members are homogenous.
FWIW, my biggest gripe about using namedtuples as light-weight immutable classes is the lingering ability to use indexing. Namedtuples are great as a backwards-compatible transition from tuples to class-like objects, which was needed for os.stat() and time.gmtime(). But in my own code I want the ability to transition from a nametuple to a class, without worrying that users of my API might have been using the getitem interface that I didn't want to implement. While people might also use the _asdict and _replace methods, it's a big temptation in inner loops to use obj[1] instead of obj.green (as with an RGB color class) because index lookup in a namedtuple is twice as fast as property lookup.
And of course in Haskell they're called produc...
boothead · 2013-05-04T10:30:51.900000
And of course in Haskell they're called product types. So given a tuple of (A, B) you can think of it as a cross product of anything from the A's and the set of B's.I believe I'd rather know how it behaved than ...
Steve · 2013-05-04T10:43:24.730000
I believe I'd rather know how it behaved than have to think of it like that. From the outside Haskell seems disciplined and difficult, but people I respect in the Python world speak highly of it. I tend to think of it as the bastard child of ML and LISP. Ignorance is Bliss.@Andrew: Well, I believe we are largely in agreeme...
Steve · 2013-05-04T10:54:54.950000
@Andrew: Well, I believe we are largely in agreement, but there is the valid point that unpacking assignments to the elements is a (somewhat) desirable feature. Does unpacking assignment rely on __getitem__(), or does it use __next__() and the iteration protocol?Older comments · Page 3 of 3
Back to post