Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #105875
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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