On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote: > On 27/03/2016 16:48, Ned Batchelder wrote: > > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote: > >> On 27/03/2016 14:47, Dennis Lee Bieber wrote: > > >> Well, that could be done in Python (not so usefully because you can't > >> take account of such info until a call is attempted), but that's not > >> what I'm talking about, which is simply allowing: > >> > >> fn(...) > >> > >> whether fn has an explicit return or not, and not allowing: > >> > >> fn # and other kinds of expression > >> > >> unless some keyword is used. (I've no idea what that might be; all the > >> best ones are taken. But I've already said a keyword can be emulated via > >> a dummy function call.) > > > > Python *could* have made it an error to have a useless expression as a > > statement. It would prevent certain kinds of errors. But it would also > > complicate the language. How do we decide what is a "useless expression"? > > Probably one that would raise eyebrows when used as an expression. Such > as 'f()+1', even though f() might have useful side-effects. > > > As we've seen this might be an expression with a side-effect: > > > > foo.bar > > > > though it would be unusual. Should it be forbidden? > > No. The language can require a prefix, or the coder can put it into a > legal form (pass it to a dummy function for example).
Yes, I misspoke, by "forbidden" of course I meant, "forbidden as statement on its own," which is what we are talking about. > > > And how do we make docstrings, which are simply string literals as > > statements? Or do we allow those? Perhaps we only allow those if they > > are the first statement in a module, class, or function? How complicated > > do we want these criteria to become? > > There would be a list of expression terms that can also form independent > statements. Not knowing Python, the list would comprise function calls > (ie. the function call is top node in the AST of the expression), and > docstrings. It's a little frustrating to discuss language design when you claim not to know Python. Perhaps you could devote some off-list time to learning it? :) > The suggestion has also been made only bare names should be disallowed, > which would probably trap most of the errors it causes, early on. As Terry pointed out, the interactive interpreter would then need different rules, since of course using bare names there is essential. The interactive interpreter is already a bit different, but you can see this is starting to snowball. > > > One of Guido's principles in designing Python was to keep it simple, > > even where that might mean people could make errors with it. This part > > of the language is no different: any expression can be a statement. > > Yeah, but even simpler would be that any statement can also be an > expression! He didn't go that far though. Nope, he didn't. As I said, it's a complex set of design considerations. No single factor is going to be pushed to the maximum. I'm not sure what point you are making. --Ned. -- https://mail.python.org/mailman/listinfo/python-list
