[Piglit] [PATCH 2/4] arb_shader_precision: add framework for calculating tolerances for complex functions

[Ilia Mirkin]

On Tue, Feb 24, 2015 at 12:13 PM, Micah Fedke
<micah.fedke at collabora.co.uk> wrote:
>
>
> On 02/19/2015 03:57 PM, Dylan Baker wrote:
>>
>> On Thu, Feb 19, 2015 at 02:27:38PM -0500, Ilia Mirkin wrote:
>>>
>>> On Thu, Feb 19, 2015 at 2:16 PM, Dylan Baker <baker.dylan.c at gmail.com>
>>> wrote:
>>>>
>>>> On Thu, Feb 19, 2015 at 02:03:41PM -0500, Ilia Mirkin wrote:
>>>>>
>>>>> On Thu, Feb 19, 2015 at 12:59 PM, Dylan Baker <baker.dylan.c at gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> +            return -1.0 if any(ret['badlands']) else map(float,
>>>>>>> ret['component_tolerances'])
>>>>>>
>>>>>>
>>>>>> Generally at this point python (both upstream and community)
>>>>>> discourage
>>>>>> the use of map and filter, with a preference for comprehensions.
>>>>>> [float(x) for x in ret['component_tolerances']] should be what you
>>>>>> want.
>>>>>
>>>>>
>>>>> Just to provide a counterpoint, I think that
>>>>>
>>>>> map(float, fooarray)
>>>>>
>>>>> is a ton more readable than
>>>>>
>>>>> list(float(x) for x in fooarray)
>>>>
>>>>
>>>> I agree that list(generator) is ugly, which is why I suggested a list
>>>> comprehension, and not a generator comprehension.
>>>
>>>
>>> Ah. But with a list comprehension the variable leaks out, so I tend to
>>> avoid it since it can, in certain situations, create horribly
>>> difficult to track down bugs. But my point still stands -- I prefer
>>
>>
>> I'll concede that map() is a pretty standard concept, especially if
>> you've worked with functional programing languages. The leaking of
>> variables is a python2.x bug, it's not present in 3.x. And honestly,
>> if you follow good practices and don't have a lot of one letter
>> variables just floating in your code you're unlikely to hit a weird bug
>> from that value leaking.
>>
>>>
>>> map(float, fooarray)
>>>
>>> to
>>>
>>> [float(x) for x in fooarray]
>>>
>>> Map is a pretty core concept in computer science and math, I think
>>> most people are familiar with it. With the comprehension, I have to
>>> read the whole thing carefully to see if it does something weird.
>>> Anyways, I think, like many things, this comes down to personal
>>> preference, in which case whatever the author of the code likes to do
>>> goes. I think that PEP8 or whatever the doc with "The One And Only
>>> True Way To Write Python" thing is went way too far.
>>>
>>>    -ilia
>>
>>
>> I think that the "one, and preferably only one" concept is one of the
>> nice things about python. Coming from a background in ruby I find that
>> refreshing.
>>
>> Anyway, since we're only using map I'll drop the suggestion.
>>
>> I am however adamant that if we're using filter and map together a
>> comprehension is much more readable.
>>
>> [f(x) for x in a_list if x is not None]
>> is much more readable than
>> filter(map(f, a_list), lambda x: x is not None)
>>
>> Dylan
>>
>
> List comprehensions (at least simple ones) make plenty of sense to me, even
> given my relative newness to python.  I had simply forgotten about them when
> I was trying to solve that problem.  However, after reading the discussion,
> I will leave these as maps for now, as I could see myself stumbling over the
> variable scope issue :p

Just for posterity, there's a difference between

[x for x in a]

and

list(x for x in a)

The former is a list comprehension and 'x' ends up in the surrounding
scope (and overwriting variable 'x' if it was there before). The
latter is a generator expression (Python 2.4+) fed to the list
function, which does not leak the variable name. Note that

list([x for x in a])

goes back to being a list comrehension, which leaks x again. If you
want to have some real fun, try

x = []
for i in xrange(10):
  x.append(lambda: i)
for func in x:
  print func()

Now _that_ was a fun debugging session.

Cheers,

  -ilia