list of constants -> tuple of constants
In a python-checkins message, Raymond stated: Raymond> Replace list of constants with tuples of constants. I understand the motivation here (the peephole optimizer can convert a tuple of constants into a single constant that need not be constructed over and over), but is the effort worth the cost of changing the logical nature of the data structures used? If lists are conceptually like vectors or arrays in other languages and tuples are like C structs or Pascal records, then by converting from list to tuple form you've somehow muddied the data structure water just to take advantage of tuples' immutability. Wouldn't it be better to have the peephole optimizer recognize the throwaway nature of lists in these contexts: for elt in [1, 2, 4, 8, 16]: ... if foo in [list, tuple]: ... (anywhere a list of constants immediately follows the "in" or "not in" keywords) and convert them into constants? The cases you converted all matched that usage. Skip
On Sun, 6 Feb 2005 10:49:05 -0600, Skip Montanaro <skip@pobox.com> wrote:
In a python-checkins message, Raymond stated:
Raymond> Replace list of constants with tuples of constants.
I understand the motivation here (the peephole optimizer can convert a tuple of constants into a single constant that need not be constructed over and over), but is the effort worth the cost of changing the logical nature of the data structures used? If lists are conceptually like vectors or arrays in other languages and tuples are like C structs or Pascal records, then by converting from list to tuple form you've somehow muddied the data structure water just to take advantage of tuples' immutability.
Wouldn't it be better to have the peephole optimizer recognize the throwaway nature of lists in these contexts:
for elt in [1, 2, 4, 8, 16]: ...
if foo in [list, tuple]: ...
(anywhere a list of constants immediately follows the "in" or "not in" keywords) and convert them into constants? The cases you converted all matched that usage.
I'm with Skip, *unless* the change is in a PROVEN TIME-CRITICAL PIECE OF CODE. Let's not hand-micro-optimize code just because we can. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
If lists are conceptually like vectors or arrays in other languages and tuples are like C structs or Pascal records,
[Skip] then
by converting from list to tuple form you've somehow muddied the data structure water just to take advantage of tuples' immutability.
In the context of literals used with the "in" operator, practices are widely divergent within the standard library and within the tutorial. Even within a single module, there were arbitrary switches between "x in [1,2,3]" and "x in (1,2,3)" and "x in 1,2,3". It seems that the list-as-arrays-tuple-as-records guideline is not meaningful or applicable in the context of the "in" operator. Proscribing tuple.__contains__ and tuple.__iter__ carrys the notion a bit too far.
Wouldn't it be better to have the peephole optimizer recognize the throwaway nature of lists
That's a good idea. Implementing it will be more straight-forward after the AST branch gets completed. Raymond
Raymond> [Skip] >> If lists are conceptually like vectors or arrays in other languages >> and tuples are like C structs or Pascal records, then by converting >> from list to tuple form you've somehow muddied the data structure >> water just to take advantage of tuples' immutability. Raymond> In the context of literals used with the "in" operator, Raymond> practices are widely divergent within the standard library and Raymond> within the tutorial. Then perhaps we should strive to make the standard library and tutorial more consistent. Answers to questions on c.l.py often advocate the standard library as a good source for example code. Raymond> It seems that the list-as-arrays-tuple-as-records guideline is Raymond> not meaningful or applicable in the context of the "in" Raymond> operator. Proscribing tuple.__contains__ and tuple.__iter__ Raymond> carrys the notion a bit too far. I agree that the presence of __contains__ and __iter__ kind of blurs the distinction between the concept of sequence and struct. Skip
On Sun, 6 Feb 2005 10:49:05 -0600, Skip Montanaro <skip@pobox.com> wrote:
Wouldn't it be better to have the peephole optimizer recognize the throwaway nature of lists in these contexts:
for elt in [1, 2, 4, 8, 16]: ...
if foo in [list, tuple]: ...
(anywhere a list of constants immediately follows the "in" or "not in" keywords) and convert them into constants? The cases you converted all matched that usage.
I think I implemented this once. I'll try to see if I can find a patch. It wasn't too difficult, but I'm not sure if the patch was clean. Neal
[Neal]
I think I implemented this once. I'll try to see if I can find a patch. It wasn't too difficult, but I'm not sure if the patch was clean.
If the opportunity arises, another worthwhile peepholer buildout would be to recognize if-elif chains that can be transformed to a single lookup and dispatch (see MAL's note in pep 275). Raymond
participants (4)
-
Guido van Rossum -
Neal Norwitz -
Raymond Hettinger -
Skip Montanaro