[Scons-dev] This morning's WTF moment

Jean-Baptiste Lab jeanbaptiste.lab at gmail.com
Tue Sep 9 04:03:36 EDT 2014


Or wouldn't it be enough to simply mandate that exists() return something
that can be tested against True/False?
If that's the case, wouldn't a bit of wrapping around and implementing the
__eq__/__neq__ descriptors (possibly __cmp__) be good enough so that we can
get to the error description when needed (if False) without breaking
existing usages?

Or maybe I'm just missing the point, in which case I apologize ;)

Cheers,

JB

On 9 September 2014 04:24, William Blevins <wblevins001 at gmail.com> wrote:

> This might be obvious, but it the exception pattern not popular in python?
> On Sep 8, 2014 9:19 PM, "Gary Oberbrunner" <garyo at oberbrunner.com> wrote:
>
>>
>> On Mon, Sep 8, 2014 at 4:13 PM, Kenny, Jason L <jason.l.kenny at intel.com>
>> wrote:
>>
>>> Ideally I always viewed this as a True False statement. I see you have
>>> it returning a tuple.
>>>
>>>
>>>
>>> I only worry that I have seen a lot push with certain python developers
>>> to say stuff like
>>>
>>>
>>>
>>> if not tool.exists():
>>>
>>>     # do something…
>>>
>>>
>>>
>>> This will not work as we will have a (True,””) or (False,””) return API.
>>> This seems to me to more complex to use and understand. At the very least
>>> east to trip up on. If we want an object returned. I think it will be
>>> better to define a error object that can be tested as True or False vs
>>> forcing tuple separation on returns values.
>>>
>>
>> Excellent point.  The 'if not tool.exists()' pattern needs to work.  I'll
>> rethink that.  Maybe something as simple as tool.exist_error() which can be
>> called just after exists() returns False...
>>
>> --
>> Gary
>>
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20140909/33d9132f/attachment.html>


More information about the Scons-dev mailing list