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