RFC: Assignment as expression (pre-PEP)

[Dustan]

On Apr 5, 2:51 pm, TimeHo... at gmail.com wrote:
> I would like to gauge interest in the following proposal:
>
> Problem:
>
> Assignment statements cannot be used as expressions.
>
> Performing a list of mutually exclusive checks that require data
> processing can cause excessive tabification.  For example, consider
> the following python snipet...
>
> temp = my_re1.match(exp)
> if temp:
>   # do something with temp
> else:
>   temp = my_re2.match(exp)
>   if temp:
>     # do something with temp
>   else:
>     temp = my_re3.match(exp)
>     if temp:
>       # do something with temp
>     else:
>       temp = my_re4.match(exp)
>
> # etc.
>
> Even with 2-space tabification, after about 20 matches, the
> indentation will take up half an 80-column terminal screen.
>
> Details:
>
> Python distinguishes between an assignment statement and an equality
> expression.  This is to force disambiguation of assignment and
> comparison so that a statement like:
>
> if x = 3:
>
> Will raise an expression rather than allowing the programmer to
> accidentally overwrite x.  Likewise,
>
> x == 3
>
> Will either return True, False or raise a NameError exception, which
> can alert the author of any potential coding mistakes since if x = 3
> (assignment) was meant, assignment being a statement returns nothing
> (though it may raise an exception depending on the underlying
> assignment function called).
>
> Because this forced disambiguation is a guiding virtue of the python
> language, it would NOT be wise to change these semantics of the
> language.
>
> Proposal:
>
> Add a new assignment-expression operator to disambiguate it completely
> from existing operators.
>
> Although any number of glyph could be used for such a new operator, I
> here propose using pascal/gnu make-like assignment.  Specifically,
>
> let:
>
> x = 3
>
> Be a statement that returns nothing;
>
> let:
>
> x == 3
>
> Be an expression that, when x is a valid, in-scope name, returns True
> or False;
>
> let:
>
> x := 3
>
> Be an expression that first assigned the value (3) to x, then returns
> x.
>
> Thus...
>
> if x = 3:
>   # Rais exception
>   pass
>
> if x == 3:
>   # Execute IFF x has a value equivalent to 3
>   pass
>
> if x := 3:
>   # Executes based on value of x after assignment;
>   # since x will be 3 and non-zero and thus represents true, always
> executed
>   pass
>
> Additional:
>
> Since python allows in-place operator assignment, (e.g. +=, *=, etc.),
> allow for these forms again by prefixing each diglyph with a colon
> (:), forming a triglyph.
>
> E.g.
>
> if x :+= 3:
>   # Executes IFF, after adding 3 to x, x represents a non-zero number.
>   pass
>
> Also note, that although the colon operator is used to denote the
> beginning of a programme block, it should be easily distinguished from
> the usage of : to denote a diglyph or triglyph assignment expression
> as well as the trinary conditional expression.  This is because
> firstly, the statement(s) following a colon (:) in existing python
> should never begin with an assignment operator.  I.e.,
>
> if x: = y
>
> is currently not valid python.  Any attempt at interpreting the
> meaning of such an expression in the current implementation of python
> is likely to fail.  Secondly, the diglyph and triglyph expressions do
> not contain spaces, further disambiguating them from existing python.
>
> Alternative proposals for dyglyph and triglyph representations for
> assignment expressions are welcome.
>
> Implementation details:
>
> When the python interpreter parser encounters a diglyph or triglyph
> beginning with a colon (:) and ending with an equals sign (=), perform
> the assignment specified by glyph[1:] and then return the value of the
> variable(s) on the left-hand side of the expression.  The assignment
> function called would be based on standard python lookup rules for the
> corresponding glyph[1:] operation (the glyph without the leading
> colon).
>
> Opposition:
>
> Adding any new operator to python could be considered code bloat.
>
> Using a colon in this way could still be ambiguous.
>
> Adding the ability to read triglyph operators in the python
> interpreter parser would require too big a code revision.
>
> Usage is too obscure.
>
> Using an assignment expression would lead to multiple conceptual
> instructions for a single python statement (e.g. first an assignment,
> then an if based on the assignment would mean two operations for a
> single if statement.)
>
> Comments:
>
> [Please comment]
>
> Jeffrey.

If you really really really really really really really really really
really really really really really really really really really really
really really really really really really really really really really
really really really really really really really really really really
really really really really really really really really really really
really really really really really really really really really really
really really really really really really really really really really
really really really really really really really really really really
want to do something like this, just create a wrapper class:

>>> class Wrapper(object):
	def __init__(self, obj):
		self.obj = obj
	def getit(self):
		return self.obj
	def setit(self, obj):
		self.obj = obj
		return obj


>>> import random
>>> x = Wrapper(0)
>>> if x.setit(random.randrange(2)):
	print 'yes!'
else:
	print 'hmmm...'

hmmm...