How to make Python interpreter a little more strict?

Chris Angelico rosuav at gmail.com
Sun Mar 27 16:59:32 EDT 2016


On Mon, Mar 28, 2016 at 7:49 AM, BartC <bc at freeuk.com> wrote:
> On 27/03/2016 21:32, Tim Chase wrote:
>>
>> On 2016-03-27 14:28, Steven D'Aprano wrote:
>
>
>>> In this case, the two lines "fnc" and "next" simply look up the
>>> function names, but without actually calling them. They're not
>>> quite "no-ops", since they can fail and raise NameError if the name
>>> doesn't exist, but otherwise they might as well be no-ops.
>>
>>
>> Which is actually useful.  I've got some 2.4 code that reads
>>
>>    try:
>>      any
>>    except NameError:
>>      def any(...):
>>        ...
>>
>> (with a similar block for all() )
>>
>> I don't want to call any() or all(), I simply want to test whether
>> they exist.
>
>
> But would it have been much of an imposition to have typed:
>
>     try:
>       test = any
>     except NameError:
>       def any(...):
>         ...
>
> ? (Or any of the half dozen ways there must be to test the existence of a
> name.)

It shifts the uselessness to "why did you assign to that name?". While
that's not too bad (and nothing like as bad as a dummy function call),
it's generally reserved for the places where Python syntax mandates an
assignment:

for _ in range(4): next(iter) # discard the headers

If you're building a linter, I would expect "name assigned to and
never used" to be its own warning; but also, the try/except block
hints that this isn't useless. Generally, "dummy expressions" like
this are going to explicitly catch at least one exception that can be
raised only in that expression (ie a really small try block). That
pretty much counts as your language-level marker for conscious dummy
expression usage.

ChrisA



More information about the Python-list mailing list