easy question on parsing python: "is not None"

Stefan Schwarzer sschwarzer at sschwarzer.net
Fri Aug 6 20:36:26 CEST 2010


Hello Peter,

On 2010-08-06 19:20, Peter Pearson wrote:
> On Fri, 06 Aug 2010 15:37:04 +0200, Stefan Schwarzer wrote:
> [snip]
>> I can imagine a case where you might want to compare a
>> string with `is`:
>>
>>     FORWARD = "forward"
>>     BACKWARD = "backward"
>>
>>     ...
>>
>>     def func(direction=FORWARD):
>>         if direction is FORWARD:
>>             ...
>>         elif direction is BACKWARD:
>>             ...
>>         else:
>>             ...
>> [...]

> Hey, that's a cute example,

Thanks!

> but . . . what a trap!  Is it
> possible to document the use-the-object-not-the-string requirement
> loudly enough that people won't get caught?

That's a good question, actually that's the nagging problem
I also have with the approach.

In production code I might write

    # Use _these_ objects to indicate directions, not string
    # constants with the same value.
    FORWARD = "forward"
    BACKWARD = "backward"

However, that won't help if people import the module and see
the strings under "global data" and so assume they're "just
strings". Moreover, if you have to write such a comment for
every use of the idiom the conciseness of the approach
vanishes.

Another view at the matter would be to let clients of the
module find out their mistake by unit tests. But of course
that's somewhat doubtful as the intention should be to write
robust instead of bug-inviting code.

I wonder if there's a way to have both the "cuteness" of the
string constants _and_ more robustness.

Stefan



More information about the Python-list mailing list