Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #105875

Re: How to make Python interpreter a little more strict?

From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Subject Re: How to make Python interpreter a little more strict?
Date 2016-03-28 07:59 +1100
Message-ID <mailman.96.1459114203.28225.python-list@python.org> (permalink)
References (1 earlier) <CAPTjJmqYuzLRGX6x6w5hpWQaB4UJ+-Dy=RXgotUxT-CO6rjYXA@mail.gmail.com> <mailman.67.1459037003.28225.python-list@python.org> <56f7536b$0$22140$c3e8da3$5496439d@news.astraweb.com> <mailman.94.1459110963.28225.python-list@python.org> <nd9gqh$rp$1@dont-email.me>

Show all headers | View raw


On Mon, Mar 28, 2016 at 7:49 AM, BartC <bc@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

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: How to make Python interpreter a little more strict? John Pote <johnhpote@o2.co.uk> - 2016-03-26 23:30 +0000
  Re: How to make Python interpreter a little more strict? BartC <bc@freeuk.com> - 2016-03-27 00:36 +0000
  Re: How to make Python interpreter a little more strict? Steven D'Aprano <steve@pearwood.info> - 2016-03-27 14:28 +1100
    Re: How to make Python interpreter a little more strict? Tim Chase <python.list@tim.thechases.com> - 2016-03-27 15:32 -0500
      Re: How to make Python interpreter a little more strict? BartC <bc@freeuk.com> - 2016-03-27 21:49 +0100
        Re: How to make Python interpreter a little more strict? Chris Angelico <rosuav@gmail.com> - 2016-03-28 07:59 +1100
        Re: How to make Python interpreter a little more strict? Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:24 +1100
  Re: How to make Python interpreter a little more strict? Nobody <nobody@nowhere.invalid> - 2016-03-28 00:26 +0100

csiph-web