PEP 285: Adding a bool type

[Bengt Richter]

On Mon, 08 Apr 2002 21:48:20 GMT, Alex Martelli <aleax at aleax.it> wrote:

>Bengt Richter wrote:
>        ...
>> Well, I guess that depends on how you define "assignment" in Python.
>
>I don't have to, as the Language Reference sees to that:
>http://www.python.org/dev/doc/devel/ref/assignment.html
>
>> ISTM there really is no such thing, in the sense of updating a named
>> storage place with new content, 
"...storage place with new content, so what goes by the name "assignment"
needs some explanation. If the statement a=b is an assignment,
then binding the name 'a' to object b is the meaning of Python
assignment as I see it."

>"Assignment statements are used to (re)bind names to values and to modify 
>attributes or items of mutable objects" -- I guess one COULD at the
>limit call an attribute "a named storage place", but it would not be a very
>fruitful thing in Python.
ISTM I did not contradict or distort that.

>
>> expression ;-) I'm not sure what that side effect should be called
>> if not assignment, since it caused the identical binding that
>> a='bee' would in that context.
>
>It's a serious logical fallacy to reason "assignment statements may
>(among other things) rebind names, therefore what rebinds a name
>is an assignment". Many bindings occur other than by assignment.
Sure, but that was not my reasoning. I was saying that assignment (not
assignment statements) in Python is effectively an alias for rebinding.
I can thus call bindings other than those caused by assignment _statements_
assignments (though I try to avoid the word, because I think its misleading
in Python). I'll even include anonymous temporary bindings in the concept,
and call those temporary "assignments" (though I know they're bindings).
            
>Would you call a for statement, a def statement, a class statement,
>or an import statement "assignments", because they also rebind
>names?!
>
To quote myself, "My criterion for judging whether it was an assignment was whether
it accomplished the same name re/binding as a normal assignment,..."
I would say they do implement Python assignment functionality as part of what they do.
I certainly would not call them assignment _statements_.

>> If it binds like a duck... ;-)
>
>Should I try to display my imitatory abilities by quacking like a duck,
>that does not justify your shooting me even if you have a hunting
>license and ducks are in season.
>
Point. I left that in against my better judgement. That should teach
me to borrow ill-fitting politicians' cliches ;-)

>> My criterion for judging whether it was an assignment was whether
>> it accomplished the same name re/binding as a normal assignment,
>> and I think it did, in the demonstrated context. So IMO Aahz's
>> quote doesn't quite remain perfectly right ;-)
>
>In many restricted contexts it's long been perfectly feasible to
>perform a binding (and nothing but that) within an expression.
>Your example was horrid -- it works "by accident" in a given
Horridness is a side issue w.r.t whether "Assignments in expressions
will never happen." But we can go there... ;-)

>implementation, in a certain restricted context, because a
>undefined behavior happens to be that way in said specific
>implementation.  One can of course do much better than that:
>
>        [x for x in (y,)][0]
>
Yes, I thought of that one too, while I was out ;-)

I think that one is actually _more_ "horrid" ;-) Why? Because it depends
on what IMO should _not_ work and my example depends on what reasonably IMO
_should_ work (if optimization issues did not take practical precedence).
IMO letting a binding side effect escape the scope of a list comprehension
is a flaw (and I'm guessing that it will be fixed). In contrast, locals()
returns a purported dictionary of local bindings, and IMO it's reasonable
to expect to be able to modify them through dictionary operations,
unless warned off conspicously.

>is an expression perfectly valid in all contexts which binds or
>rebinds name x to the same value as name y is bound to and
>also has that value as its value-as-expression.  It doesn't
>take all that much Python knowledge to build it, either.
>
Nope, I thought of it too ;-)

>So, whatever you could do in a language that allowed assignments
>in expressions you could do in Python via that hard-to-read way, e.g.:
>
>while [x for x in (getnext(23),)][0]:
>    frobnicate(x)
>
>is the Python (but NOT Pythonic) equivalent of C's
>
>while(x=getnext(23))
>    frobnicate(x);
>
>That doesn't affect the "perfectly right" status of Aahz's quote, either.
>
Nope. It's a "horrid" example confirming to me what that status is ;-)


Or perhaps I should say was: I saw another post from Aahz, which said,
"""
    I define "assignment" in Python as being precisely equal to "=".

"""
So that changes the ball game and clinches it. He's perfectly right, unless Guido
does something to change the situation. ;-)

Regards,
Bengt Richter