Re: [Python-ideas] if expensive_computation() as x:
Isn't this whole concept just a way of sneaking in assignments-as-expressions? I'd almost say it would be preferable to _actually_ allow assignments as expressions [maybe with an alternate operator like := if we're too worried about people making a mistake in a condition], rather than invent a new kind of scope and come up with rules as to where this new syntax can be used.
On Fri, Feb 14, 2014 at 03:31:19PM -0500, random832@fastmail.us wrote:
Isn't this whole concept just a way of sneaking in assignments-as-expressions?
Certainly is.
I'd almost say it would be preferable to _actually_ allow assignments as expressions [maybe with an alternate operator like := if we're too worried about people making a mistake in a condition],
-1 on this. Python is not C and should not emulate it's mistakes, no matter how tempting they seem :-) -- Steven
On Fri, Feb 14, 2014, at 16:20, Steven D'Aprano wrote:
-1 on this. Python is not C and should not emulate it's mistakes, no matter how tempting they seem :-)
= as assignment is one of C's mistakes. I propose abandoning it in Python 4000. Absent that, assignments as expressions is no longer obviously a mistake. Other than the specific syntax, the only difference between this proposal and assignment expressions is that this proposal also invents a new form of block scope.
On Fri, Feb 14, 2014 at 05:10:53PM -0500, random832@fastmail.us wrote:
On Fri, Feb 14, 2014, at 16:20, Steven D'Aprano wrote:
-1 on this. Python is not C and should not emulate it's mistakes, no matter how tempting they seem :-)
= as assignment is one of C's mistakes. I propose abandoning it in Python 4000.
Absent that, assignments as expressions is no longer obviously a mistake.
I think it is. Mathematicians have been performing algorithmic manipulations rather similar to programming for thousands of years, and I do not believe that they have anything like assignment as expressions. (Or if they do, they're in advanced fields which I have not come across.) Instead, they either pre- or post-define the variables they need. # pre-define y = something complicated related to x z = function(y + 1/y) # post-define z = function(y + 1/y) where y = something complicated related to x They don't "in-define": z = function(something complicated related to x as y + 1/y) Mathematicians are notorious for inventing user-hostile but terse syntax. If they don't do definitions-as-expressions, there is likely to be a *really* good reason for it. C using = for assignment-as-expression just compounds the problem, it doesn't create the fundamental problem that sticking assignments in the middle of an expression makes the expression hard for human beings to parse. -- Steven
A problem with the "list of expensive functions" style is that not everything we want to do will necessarily be a pure function. I.e. if it is, this is great: fs = [expensive_1, expensive_2, expensive_3] for f in fs: x = f(known, args, here) if x: break But sometimes you want more general expressions that might be expensive. Nonetheless, using while/break gets us the early exit just as well: while True: x = expensive_1() + 1 if x: break x = expensive_2() // 2 if x: break x = expensive_3() % 3 if x: break x = default_value break Honestly that isn't very verbose. And also, while the def/return approach is similar, it *does* require passing in all the relevant lexical elements needed into the function (well, or using a closure), and that's a bit more bookkeeping possibly. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
participants (3)
-
David Mertz -
random832＠fastmail.us -
Steven D'Aprano