Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Mon, 03 May 2010 06:37:49 +0200, Alf P. Steinbach wrote:

 * Terry Reedy:
 * Alf P. Steinbach:
 * Aahz:

 and sometimes
 they rebind the original target to the same object.

 At the Python level that seems to be an undetectable null-operation.

 If you try t=(1,2,3); t[1]+=3, if very much matters that a rebind
 occurs.
 
 Testing:
 
 test lang=py3
   t = ([], [], [])
   t
 ([], [], [])
   t[0] += [blah]
 Traceback (most recent call last):
File stdin, line 1, in module
 TypeError: 'tuple' object does not support item assignment
   t
 (['blah'], [], [])
   _
 /test
 
 Yep, it matters.
 
 Is this change-but-raise-exception a bug?
 
 I seem to have a knack for running into bugs. :-)

No, I don't believe so -- I believe that it is behaving exactly as 
advertised. But it is absolutely a gotcha.

Consider:


 class K(object):
... def __init__(self, value=0):
... self.value = value
... def __add__(self, other):
... self.value = self.value + other
... return self
... def __str__(self):
... return %s % self.value
... __repr__ = __str__
...
 x = K(42)
 x + 5
47
 t = (None, x)
 t
(None, 47)

 t[1] + 3
50
 t
(None, 50)
 t[1] += 1
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: 'tuple' object does not support item assignment
 t
(None, 51)


Unintuitive, yes. Possibly a bad design, maybe. Surprising, absolutely. 
But not a bug, as it's working exactly as promised. += is conceptually 
two steps: perform an addition, and perform an assignment afterward. That 
addition is sometimes performed in-place, but regardless of whether it is 
or not, the assignment is always attempted.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Peter Otten]

Alf P. Steinbach wrote:

 test lang=py3
  t = ([], [], [])
  t
 ([], [], [])
  t[0] += [blah]
 Traceback (most recent call last):
 File stdin, line 1, in module
 TypeError: 'tuple' object does not support item assignment
  t
 (['blah'], [], [])
  _
 /test
 
 Yep, it matters.
 
 Is this change-but-raise-exception a bug?

No.

a[0] += b

translates to

a.__setitem__(0, a.__getitem__(0).__iadd__(b))

assuming a[0] has an __iadd__() method. It should be obvious that only the 
the last operation, the outer a.__setitem__(...), will fail here.
A possible fix might be a changed order of evaluation:

_internal_set = a.__setitem__
_internal_set(0, a.__getitem__(0).__iadd__(b))

I don't know if there are arguments against this other than increased 
compiler complexity.

Or one could argue that

a += b

should have been implemented as

a = a + b

or

a = a.__add__(b)

which is currently used as the fallback when there is no __iadd__() method 
and which gives a more intuitive behaviour at the cost of a greater 
overhead. But it's a little late for that discussion, for that language.

Peter

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Terry Reedy]

On 5/3/2010 12:37 AM, Alf P. Steinbach wrote:

* Terry Reedy:

* Alf P. Steinbach:

* Aahz:



and sometimes
they rebind the original target to the same object.


At the Python level that seems to be an undetectable null-operation.


If you try t=(1,2,3); t[1]+=3, if very much matters that a rebind occurs.


Testing:

test lang=py3
  t = ([], [], [])
  t
([], [], [])
  t[0] += [blah]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'tuple' object does not support item assignment
  t
(['blah'], [], [])
  _
/test

Yep, it matters.


So one should instead write t[0].extend('blah') to the same effect, but 
without the exception raising assignment attempt, when that is what one 
really means ;-).


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Lie Ryan]

On 05/02/10 10:58, Steven D'Aprano wrote:
  And Python's object system
  makes it that the argument to __getattr__ is always a string even though
  there might be a valid variable that corresponds to it:
 That is nothing to do with the object system, it is related to the 
 semantics of Python syntax. a.b doesn't mean apply the binary dot 
 operator to arguments a and b. It is syntactic sugar for look for an 
 attribute named 'b' on object a. As such, the operands that __getattr__ 
 receives are the object a and the *name* b (implemented as a string).

You just described *exactly* the reason why dot is not, and cannot be an
operator.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Lie Ryan]

On 05/02/10 10:58, Steven D'Aprano wrote:
 On Sun, 02 May 2010 05:08:53 +1000, Lie Ryan wrote:
 
  On 05/01/10 11:16, Steven D'Aprano wrote:
  On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote:
  
  In practice though, I think that's a difference that makes no
  difference. It walks like an operator, it swims like an operator, and
  it quacks like an operator.
  
  
  Nope it's not. A full-time operator in python have a reflected version
  (e.g. __radd__), which dot does not have. 
 What are the reflected versions of __eq__ and __ne__ (binary == and != 
 operators)?

Python do not have them now, but it does make sense if python have
them[1]. OTOH, given current python's language semantic, __rgetattr__
doesn't make any sense; adding __rgetattr__ would require a quite
fundamental change to the language's semantic, primarily how attribute
resolution works.

[1] though they'd probably be dismissed as bad idea since equality and
inequality are supposed to be a symmetric relation; reflected
(in)equality makes it way too easy to break that premise

 And __neg__, __pos__ and __inv__ (for the unary - + and ~ operators)?
 
 And the three-argument form of __pow__ for power(1, 2, x)?

I know you're a famed nitpicker, but don't be silly, reflected operator,
by definition, only makes sense for binary operator.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Terry Reedy]

On 5/2/2010 1:05 AM, Alf P. Steinbach wrote:

On 02.05.2010 06:06, * Aahz:



and sometimes
they rebind the original target to the same object.


At the Python level that seems to be an undetectable null-operation.


If you try t=(1,2,3); t[1]+=3, if very much matters that a rebind occurs.


Granted one could see something going on in a machine code or byte code
debugger. But making that distinction (doing nothing versus
self-assignment) at the Python level seems, to me, to be meaningless.


Please do not confuse things. Augmented *assignment* must be understood 
as assignment. Failure to do so leads (and has lead) newbies into 
confusion, and puzzled posts on this list.


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Sun, 02 May 2010 16:28:28 +1000, Lie Ryan wrote:

 On 05/02/10 10:58, Steven D'Aprano wrote:
  And Python's object system
  makes it that the argument to __getattr__ is always a string even
  though there might be a valid variable that corresponds to it:
 That is nothing to do with the object system, it is related to the
 semantics of Python syntax. a.b doesn't mean apply the binary dot
 operator to arguments a and b. It is syntactic sugar for look for an
 attribute named 'b' on object a. As such, the operands that
 __getattr__ receives are the object a and the *name* b (implemented as
 a string).
 
 You just described *exactly* the reason why dot is not, and cannot be an
 operator.

This would be relevant if I said it was an operator. I did not. I said it 
was a de facto operator that behaves similarly enough to operators as to 
make it reasonable to talk about dot operator. I still stand by that.

That doesn't imply that Python's implementation of a.b has to be 
identical in every last detail to Python's implementation of a+b, because 
it clearly isn't. But there are sufficient similarities to justify saying 
that it duck-types as an operator. This isn't meant to be a vigorous 
statement of fact in the same manner than CPython implements lists as 
arrays of pointers is a statement of fact. It's meant to be a hand-wavy 
dot act kinda-sorta like an operator manner.

I'm sorry if I failed to make that clear enough. I thought that 
explicitly stating that it wasn't a real operator would be sufficient.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Sun, 02 May 2010 17:09:36 +1000, Lie Ryan wrote:

 On 05/02/10 10:58, Steven D'Aprano wrote:
 On Sun, 02 May 2010 05:08:53 +1000, Lie Ryan wrote:
 
  On 05/01/10 11:16, Steven D'Aprano wrote:
  On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote:
  
  In practice though, I think that's a difference that makes no
  difference. It walks like an operator, it swims like an operator,
  and it quacks like an operator.
  
  
  Nope it's not. A full-time operator in python have a reflected
  version (e.g. __radd__), which dot does not have.
 What are the reflected versions of __eq__ and __ne__ (binary == and !=
 operators)?
 
 Python do not have them now, but it does make sense if python have
 them[1]. OTOH, given current python's language semantic, __rgetattr__
 doesn't make any sense; adding __rgetattr__ would require a quite
 fundamental change to the language's semantic, primarily how attribute
 resolution works.
 
 [1] though they'd probably be dismissed as bad idea since equality and
 inequality are supposed to be a symmetric relation; reflected
 (in)equality makes it way too easy to break that premise
 
 And __neg__, __pos__ and __inv__ (for the unary - + and ~ operators)?
 
 And the three-argument form of __pow__ for power(1, 2, x)?
 
 I know you're a famed nitpicker, but don't be silly, reflected operator,
 by definition, only makes sense for binary operator.

Binary operators aren't the only kind of operator, and you claimed that:

A full-time operator in python have a reflected version.

But there are full-time operators that don't have reflected versions, so 
your claim is just *wrong*. It would still be wrong even if you had 
limited yourself to binary operators.

I have agreed with you that there are useful things people might want to 
do (e.g. function composition) that you can't do because the dot 
operator isn't a *real* operator with exactly the same semantics as 
plus operator, multiply operator and friends. I think we're in 
violent agreement, and merely disagreeing over semantics. There's no need 
to continue arguing against a position I haven't actually taken :)


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Sun, 02 May 2010 04:04:11 -0400, Terry Reedy wrote:

 On 5/2/2010 1:05 AM, Alf P. Steinbach wrote:
 On 02.05.2010 06:06, * Aahz:
 
 and sometimes
 they rebind the original target to the same object.

 At the Python level that seems to be an undetectable null-operation.
 
 If you try t=(1,2,3); t[1]+=3, if very much matters that a rebind
 occurs.
 
 Granted one could see something going on in a machine code or byte code
 debugger. But making that distinction (doing nothing versus
 self-assignment) at the Python level seems, to me, to be meaningless.
 
 Please do not confuse things. Augmented *assignment* must be understood
 as assignment. Failure to do so leads (and has lead) newbies into
 confusion, and puzzled posts on this list.

I think that if you think *only* about Python's standard namespaces, self-
assignment is more or less a no-op. I can't think of any way that x = x 
could do anything other than use CPU cycles, *if* you limit yourself to 
the standard global or function local namespaces.

But if you think about custom namespace types, and item assignment (e.g. 
the example you gave with a tuple), the situation becomes different. 
Here's a nice example, using Python 3.1:

 class B(A):  # class A defined elsewhere -- see below.
... x = 1
... x = x
...
Traceback (most recent call last):
  File stdin, line 1, in module
  File stdin, line 3, in B
  File stdin, line 4, in __setitem__
TypeError: can't rebind constants

Thus proving that self-assignment is not necessarily a no-op. How did I 
make that work? It takes a custom dict and a bit of metaclass magic:


class ConstantNamespace(dict):
def __setitem__(self, key, value):
if key in self:
raise TypeError(can't rebind constants)
super(ConstantNamespace, self).__setitem__(key, value)

class WriteOnceClass(type):
@classmethod
def __prepare__(metacls, name, bases):
return ConstantNamespace()
def __new__(cls, name, bases, classdict):
return type.__new__(cls, name, bases, classdict)

class A(metaclass=WriteOnceClass):
pass



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Albert van der Horst]

In article mailman.2429.1272646255.23598.python-l...@python.org,
Jean-Michel Pichavant  jeanmic...@sequans.com wrote:
Jabapyth wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:

 vbl.=func(args)

 this would be equivalent to

 vbl = vbl.func(args)

 example:

 foo = Hello world
 foo.=split( )
 print foo
 # ['Hello', 'world']

 and I guess you could generalize this to

 vbl.=[some text]
 #
 vbl = vbl.[some text]

 e.g.

 temp.=children[0]
 # temp = temp.children[0]

 thoughts?

Useless if you use meaningful names for your variables  attributes.

It may happen that one object attribute refer to an object of the same
type, but it is quite rare that both can share the same name anyway.

Possible use cases:

1/
car = Car()
car = car.wheel # ???

2/
wheel = Car() # ???
wheel = wheel.wheel # ???

3/
currentCar = Car()
currentCar = currentCar.nextCar

The syntax you prose will be applicable on very little assignements (use
case 3). I'm not sure it's worth it.

Note how related it is to the requirement to have a _radd_ operator.

It amounts to the argument that
a op= b
requires that a and b have somewhat similar type, or that
the type of a doesn't really change as a result from the operation.

This is IMHO an argument against the .= pseudo-operator.


JM

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
alb...@spearc.xs4all.nl =n http://home.hccnet.nl/a.w.m.van.der.horst

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Alf P. Steinbach]

* Terry Reedy:

* Alf P. Steinbach:

* Aahz:



and sometimes
they rebind the original target to the same object.


At the Python level that seems to be an undetectable null-operation.


If you try t=(1,2,3); t[1]+=3, if very much matters that a rebind occurs.


Testing:

test lang=py3
 t = ([], [], [])
 t
([], [], [])
 t[0] += [blah]
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: 'tuple' object does not support item assignment
 t
(['blah'], [], [])
 _
/test

Yep, it matters.

Is this change-but-raise-exception a bug?

I seem to have a knack for running into bugs. :-)



Granted one could see something going on in a machine code or byte code
debugger. But making that distinction (doing nothing versus
self-assignment) at the Python level seems, to me, to be meaningless.


Please do not confuse things. Augmented *assignment* must be understood
as assignment. Failure to do so leads (and has lead) newbies into
confusion, and puzzled posts on this list.


OK.

But I think it would be less confusing, less breaking of expectations, if, for 
the example above, += reduced to the functionality of extend(), with no x.



Cheers,  thanks,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Simon]

Hay I got a better idea. If you put two dots (..) on a line by itself it
means
execute the previous line again!

On 1 May 2010 07:08, Patrick Maupin pmau...@gmail.com wrote:

 On Apr 30, 11:04 am, Jabapyth jabap...@gmail.com wrote:
  At least a few times a day I wish python had the following shortcut
  syntax:
 
  vbl.=func(args)
 
  this would be equivalent to
 
  vbl = vbl.func(args)
 
  example:
 
  foo = Hello world
  foo.=split( )
  print foo
  # ['Hello', 'world']
 
  and I guess you could generalize this to
 
  vbl.=[some text]
  #
  vbl = vbl.[some text]
 
  e.g.
 
  temp.=children[0]
  # temp = temp.children[0]
 
  thoughts?

 First thought:  good luck getting something like this through.
 Probably not going to happen, although I do find the idea very
 intriguing.

 Second thought:  I don't like the proposed syntax at all.

 +=, -=, /=, *=, etc.  conceptually (and, if lhs object supports in-
 place operator methods, actually) *modify* the lhs object.

 Your proposed .= syntax conceptually *replaces* the lhs object
 (actually, rebinds the lhs symbol to the new object).

 If this were to be deemed worthy of the language, I would think a
 better syntax would be something like:

  mystring = .upper()
  mystring = .replace('a', 'b')

 etc.

 The '=' shows clearly that mystring is being rebound to a new object.

 As Steven has shown, '.' functions as an operator, so if this change
 were accepted, in reality you would probably be able to write:

 mystring = . upper()
 mystring=.upper()

 or whatever.  But the canonical form would probably be with a space
 before the period but not after.

 Regards,
 Pat
 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Tim Chase]

On 05/01/2010 12:08 AM, Patrick Maupin wrote:

+=, -=, /=, *=, etc.  conceptually (and, if lhs object supports in-
place operator methods, actually) *modify* the lhs object.

Your proposed .= syntax conceptually *replaces* the lhs object
(actually, rebinds the lhs symbol to the new object).


The += family of operators really do rebind the symbol, not 
modify the object.


   from decimal import Decimal
   d = Decimal(42)
   e = Decimal(18)
   orig = d
   d += e
   d
  Decimal(60)
   e
  Decimal(18)
   orig
  Decimal(42)
   d is orig
  False

If your suggestion that += *modifies* the object, then orig would 
now unintuitively contain 60 and d is orig would return True.


This doesn't preclude you from implementing a self-mutating += 
style __add__ method and returning self, but it's usually a bad 
idea unless it's dire for performance (and even then, think it 
over a couple times).


-tkc



--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Stefan Behnel]

Tim Chase, 01.05.2010 14:13:

On 05/01/2010 12:08 AM, Patrick Maupin wrote:

+=, -=, /=, *=, etc. conceptually (and, if lhs object supports in-
place operator methods, actually) *modify* the lhs object.

Your proposed .= syntax conceptually *replaces* the lhs object
(actually, rebinds the lhs symbol to the new object).


The += family of operators really do rebind the symbol, not modify the
object.

  from decimal import Decimal
  d = Decimal(42)
  e = Decimal(18)
  orig = d
  d += e
  d
Decimal(60)
  e
Decimal(18)
  orig
Decimal(42)
  d is orig
False

If your suggestion that += *modifies* the object, then orig would now
unintuitively contain 60 and d is orig would return True.

This doesn't preclude you from implementing a self-mutating += style
__add__ method and returning self, but it's usually a bad idea unless
it's dire for performance (and even then, think it over a couple times).


It's not like this was unprecedented in Python, though:

  Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
  [GCC 4.4.3] on linux2
  Type help, copyright, credits or license for more information.
   l = [1,2,3]
   a = l
   l += [4,5,6]
   l
  [1, 2, 3, 4, 5, 6]
   a
  [1, 2, 3, 4, 5, 6]

And I'm pretty sure this wasn't just done for performance reasons. Mutable 
data types behave that way.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Alf P. Steinbach]

On 01.05.2010 14:13, * Tim Chase:

On 05/01/2010 12:08 AM, Patrick Maupin wrote:

+=, -=, /=, *=, etc. conceptually (and, if lhs object supports in-
place operator methods, actually) *modify* the lhs object.

Your proposed .= syntax conceptually *replaces* the lhs object
(actually, rebinds the lhs symbol to the new object).


The += family of operators really do rebind the symbol, not modify the
object.

  from decimal import Decimal
  d = Decimal(42)
  e = Decimal(18)
  orig = d
  d += e
  d
Decimal(60)
  e
Decimal(18)
  orig
Decimal(42)
  d is orig
False

If your suggestion that += *modifies* the object, then orig would now
unintuitively contain 60 and d is orig would return True.


In some cases += modifies the object. For CPython this is an optimization for 
the 'str' type, reducing to O(n) time the common newbie O(n^2) loops. The 
criterion for doing it is that there is exactly 1 reference (as is the case 
after a first append, subsequent appends can just modify).




This doesn't preclude you from implementing a self-mutating += style
__add__ method and returning self, but it's usually a bad idea unless
it's dire for performance (and even then, think it over a couple times).


Agreed, at the Python level one doesn't in general have the necessary 
information to do it safely. Nothwithstanding the current CPython and Jython 
documentation error of sys.getrefcount (or whatever the name was) that indicates 
that it's available in any implementation.



Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Lie Ryan]

On 05/01/10 11:16, Steven D'Aprano wrote:
 On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote:
 
 In practice though, I think that's a difference that makes no difference. 
 It walks like an operator, it swims like an operator, and it quacks like 
 an operator.
 

Nope it's not. A full-time operator in python have a reflected version
(e.g. __radd__), which dot does not have. And Python's object system
makes it that the argument to __getattr__ is always a string even though
there might be a valid variable that corresponds to it:

a = MyClass()
b = MyClass()
print a . b

I've often wanted to figure out a way to (ab)use python's dot operator
for function composition (i.e. f.g(x) == f(g(x)) ). There's no way to
do it, not without being way too hackish. OTOH, doing so is quite
trivial with regular operators. In short, unless there's __rgetattr__
and unless you can refer to the right-hand operand as an object[1], dot
doesn't quack like an operator.

[1] well, technically string is an object, but you get what I mean
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Patrick Maupin]

On May 1, 7:13 am, Tim Chase t...@thechases.com wrote:
 On 05/01/2010 12:08 AM, Patrick Maupin wrote:

  +=, -=, /=, *=, etc.  conceptually (and, if lhs object supports in-
  place operator methods, actually) *modify* the lhs object.

  Your proposed .= syntax conceptually *replaces* the lhs object
  (actually, rebinds the lhs symbol to the new object).

 The += family of operators really do rebind the symbol, not
 modify the object.

     from decimal import Decimal
     d = Decimal(42)
     e = Decimal(18)
     orig = d
     d += e
     d
    Decimal(60)
     e
    Decimal(18)
     orig
    Decimal(42)
     d is orig
    False

 If your suggestion that += *modifies* the object, then orig would
 now unintuitively contain 60 and d is orig would return True.

Well, I wrote conceptually (which I believe is true; it's certainly
true for me) and sometimes actually (which I know is true):

 x = [1,2,3,4,5]
 y = x
 x += [6]
 y
[1, 2, 3, 4, 5, 6]


 x = set()
 y = x
 x |= set([1])
 y
set([1])

SO, if you find those results unintuitive, perhaps you should
upgrade your understanding of python.  Personally, I don't find any of
the results I gave, or the results you gave, surprising, so I'm not
saying my conceptually and sometimes actually modifies the result is
right for *you* but it works great for me. :-)

 This doesn't preclude you from implementing a self-mutating +=
 style __add__ method and returning self, but it's usually a bad
 idea unless it's dire for performance (and even then, think it
 over a couple times).

Well, you should submit a bug report to fix the operation of lists and
sets for a starter.

But first, you might want to read PEP 203 -- augmented assignments.  I
particularly like the section which says:

The idea behind augmented assignment in Python is that it isn't just
an easier way to write the common practice of storing the result of a
binary operation in its left-hand operand, but also a way for the left-
hand operand in question to know that it should operate `on itself',
rather than creating a modified copy of itself.

There are a lot of sections which have a similar flavor.  If (which I
doubt), the augmented dot is accepted, it won't necessarily have the
same meaning.  x = x.foo could replace x with any other kind of
object, and I view it as a replacement, while I view x += foo as a
modification.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[D'Arcy J.M. Cain]

On Sun, 02 May 2010 05:08:53 +1000
Lie Ryan lie.1...@gmail.com wrote:
 On 05/01/10 11:16, Steven D'Aprano wrote:
  On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote:
  
  In practice though, I think that's a difference that makes no difference. 
  It walks like an operator, it swims like an operator, and it quacks like 
  an operator.
  
 
 Nope it's not. A full-time operator in python have a reflected version

Hi.  Please watch the attributions.  I didn't write that.  I was the
one who said that '.' was not an operator.

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Sun, 02 May 2010 05:08:53 +1000, Lie Ryan wrote:

 On 05/01/10 11:16, Steven D'Aprano wrote:
 On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote:
 
 In practice though, I think that's a difference that makes no
 difference. It walks like an operator, it swims like an operator, and
 it quacks like an operator.
 
 
 Nope it's not. A full-time operator in python have a reflected version
 (e.g. __radd__), which dot does not have. 

What are the reflected versions of __eq__ and __ne__ (binary == and != 
operators)?

And __neg__, __pos__ and __inv__ (for the unary - + and ~ operators)?

And the three-argument form of __pow__ for power(1, 2, x)?



 And Python's object system
 makes it that the argument to __getattr__ is always a string even though
 there might be a valid variable that corresponds to it:

That is nothing to do with the object system, it is related to the 
semantics of Python syntax. a.b doesn't mean apply the binary dot 
operator to arguments a and b. It is syntactic sugar for look for an 
attribute named 'b' on object a. As such, the operands that __getattr__ 
receives are the object a and the *name* b (implemented as a string).

Also, the implementation of attribute lookup is quite complex, with all 
sorts of special cases and optimizations.


 a = MyClass()
 b = MyClass()
 print a . b
 
 I've often wanted to figure out a way to (ab)use python's dot operator
 for function composition (i.e. f.g(x) == f(g(x)) ). There's no way to
 do it, not without being way too hackish.

That's a good example of where the difference does make a difference.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:

 On 05/01/2010 12:08 AM, Patrick Maupin wrote:
 +=, -=, /=, *=, etc.  conceptually (and, if lhs object supports in-
 place operator methods, actually) *modify* the lhs object.

 Your proposed .= syntax conceptually *replaces* the lhs object
 (actually, rebinds the lhs symbol to the new object).
 
 The += family of operators really do rebind the symbol, not modify the
 object.

They potentially do both, depending on the object, even for built-ins.


 from decimal import Decimal
[...]

I'm not sure why you took the trouble to import Decimal for this example, 
when you could have shown the same thing with built-ins int or float. All 
three types are immutable.

A counter example with a mutable type:

 a = []
 b = a
 a += [2]
 a
[2]
 b
[2]

thus demonstrating that __iadd__ modifies in place as well as rebinds for 
at least one mutable type.

 This doesn't preclude you from implementing a self-mutating += style
 __add__ method and returning self, but it's usually a bad idea 

Obviously the Python dev team don't agree with that :)

Just to prove that += for lists is not an accident:

 a = set()
 b = a
 a |= set([1])
 a
set([1])
 b
set([1])



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Chris Rebert]

On Sat, May 1, 2010 at 6:32 PM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote:
 On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
 This doesn't preclude you from implementing a self-mutating += style
 __add__ method and returning self, but it's usually a bad idea

 Obviously the Python dev team don't agree with that :)

 Just to prove that += for lists is not an accident:

 a = set()
 b = a
 a |= set([1])
 a
 set([1])
 b
 set([1])

In both cases, __iOP__ operator methods are being used, not vanilla
__OP__ methods, so neither of your examples are relevant to Mr.
Chase's point.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Sat, 01 May 2010 19:03:04 -0700, Chris Rebert wrote:

 On Sat, May 1, 2010 at 6:32 PM, Steven D'Aprano
 st...@remove-this-cybersource.com.au wrote:
 On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
 This doesn't preclude you from implementing a self-mutating += style
 __add__ method and returning self, but it's usually a bad idea

 Obviously the Python dev team don't agree with that :)

 Just to prove that += for lists is not an accident:
[...]
 In both cases, __iOP__ operator methods are being used, not vanilla
 __OP__ methods, so neither of your examples are relevant to Mr. Chase's
 point.


I'm sorry, I read Tim's reference to __add__ (instead of __iadd__) as a 
typo. Having __add__ mutate self would be a strange thing to do.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Patrick Maupin]

On May 1, 9:03 pm, Chris Rebert c...@rebertia.com wrote:
 In both cases, __iOP__ operator methods are being used, not vanilla
 __OP__ methods, so neither of your examples are relevant to Mr.
 Chase's point.

Well, Tim's main assertion was: The += family of operators really do
rebind the symbol, not modify the object.

So, using __iadd__ to disprove this blanket assertion is certainly
relevant.

Regards,
Pat


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Aahz]

In article 4bdcd631$0$27782$c3e8...@news.astraweb.com,
Steven D'Aprano  st...@remove-this-cybersource.com.au wrote:
On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
 
 The += family of operators really do rebind the symbol, not modify the
 object.

They potentially do both, depending on the object, even for built-ins.

No, they always rebind; sometimes they modify the object and sometimes
they rebind the original target to the same object.
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

It is easier to optimize correct code than to correct optimized code.
--Bill Harlan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Alf P. Steinbach]

On 02.05.2010 06:06, * Aahz:

In article4bdcd631$0$27782$c3e8...@news.astraweb.com,
Steven D'Apranost...@remove-this-cybersource.com.au  wrote:

On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:


The += family of operators really do rebind the symbol, not modify the
object.


They potentially do both, depending on the object, even for built-ins.


No, they always rebind; sometimes they modify the object


If they always rebind and sometimes modify object then they potentially do 
both, and so the No at the start of the sentence contradicts this later part.




and sometimes
they rebind the original target to the same object.


At the Python level that seems to be an undetectable null-operation. Granted one 
could see something going on in a machine code or byte code debugger. But making 
that distinction (doing nothing versus self-assignment) at the Python level 
seems, to me, to be meaningless.



Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Chris Rebert]

On Sat, May 1, 2010 at 10:05 PM, Alf P. Steinbach al...@start.no wrote:
 On 02.05.2010 06:06, * Aahz:
 In article4bdcd631$0$27782$c3e8...@news.astraweb.com,
 Steven D'Apranost...@remove-this-cybersource.com.au  wrote:

 On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:

 The += family of operators really do rebind the symbol, not modify the
 object.

 They potentially do both, depending on the object, even for built-ins.

 No, they always rebind; sometimes they modify the object

 If they always rebind and sometimes modify object then they potentially do
 both, and so the No at the start of the sentence contradicts this later
 part.


 and sometimes
 they rebind the original target to the same object.

 At the Python level that seems to be an undetectable null-operation. Granted
 one could see something going on in a machine code or byte code debugger.
 But making that distinction (doing nothing versus self-assignment) at the
 Python level seems, to me, to be meaningless.

There are some circumstances where the subtle distinction matters.
Consider x.y += z where x is an instance of a class that overrides
__setattr__ and __getattribute__ and x.y results in a mutable object.
Not doing the assignment can result in a noticeable difference in
behavior since __setattr__ won't get called. Yes, this is a slightly
obscure case, but it does come up.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Python dot-equals (syntax proposal)

[Jabapyth]

At least a few times a day I wish python had the following shortcut
syntax:

vbl.=func(args)

this would be equivalent to

vbl = vbl.func(args)

example:

foo = Hello world
foo.=split( )
print foo
# ['Hello', 'world']

and I guess you could generalize this to

vbl.=[some text]
#
vbl = vbl.[some text]

e.g.

temp.=children[0]
# temp = temp.children[0]

thoughts?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[J. Cliff Dyer]

That's kind of a nifty idea.  However, python is currently under a
syntax moratorium.  No syntax changes will be accepted for at least 24
months starting from the release date of Python 3.1.  See more details
here: http://www.python.org/dev/peps/pep-3003/

Cheers,
Cliff


On Fri, 2010-04-30 at 09:04 -0700, Jabapyth wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:
 
 vbl.=func(args)
 
 this would be equivalent to
 
 vbl = vbl.func(args)
 
 example:
 
 foo = Hello world
 foo.=split( )
 print foo
 # ['Hello', 'world']
 
 and I guess you could generalize this to
 
 vbl.=[some text]
 #
 vbl = vbl.[some text]
 
 e.g.
 
 temp.=children[0]
 # temp = temp.children[0]
 
 thoughts?


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Stefan Behnel]

J. Cliff Dyer, 30.04.2010 18:20:

On Fri, 2010-04-30 at 09:04 -0700, Jabapyth wrote:

At least a few times a day I wish python had the following shortcut
syntax:

vbl.=func(args)

this would be equivalent to

vbl = vbl.func(args)

example:

foo = Hello world
foo.=split( )
print foo
# ['Hello', 'world']

and I guess you could generalize this to

vbl.=[some text]
#
vbl = vbl.[some text]

e.g.

temp.=children[0]
# temp = temp.children[0]

thoughts?


That's kind of a nifty idea.  However, python is currently under a
syntax moratorium.  No syntax changes will be accepted for at least 24
months starting from the release date of Python 3.1.  See more details
here: http://www.python.org/dev/peps/pep-3003/


In any case, the right place to discuss this is the python-ideas list.

Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[D'Arcy J.M. Cain]

On Fri, 30 Apr 2010 09:04:59 -0700 (PDT)
Jabapyth jabap...@gmail.com wrote:
 foo = Hello world
 foo.=split( )

Isn't;

foo = Hello world
bar = foo.split() # side note - split() splits on whitespace by default

so much clearer?  Do you really want to see Python turn into Perl?

However, if you really want to propose this you should be clear about
which of the following you mean.

foo .= split()
 or
foo. = split()

I assume you mean the former to be analagous to += and friends but I
am not sure since . isn't an operator.

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Peter Otten]

Jabapyth wrote:

 At least a few times a day I wish python had the following shortcut
 syntax:
 
 vbl.=func(args)
 
 this would be equivalent to
 
 vbl = vbl.func(args)
 
 example:
 
 foo = Hello world
 foo.=split( )
 print foo
 # ['Hello', 'world']

Extending a language comes at a cost, too. A language with 1000 superb 
features will be much harder to use than one with 10 or 20. 

In that spirit I suggest a thought experiment: which two features would you 
kick out of Python to get your new one in?

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Jean-Michel Pichavant]

Jabapyth wrote:

At least a few times a day I wish python had the following shortcut
syntax:

vbl.=func(args)

this would be equivalent to

vbl = vbl.func(args)

example:

foo = Hello world
foo.=split( )
print foo
# ['Hello', 'world']

and I guess you could generalize this to

vbl.=[some text]
#
vbl = vbl.[some text]

e.g.

temp.=children[0]
# temp = temp.children[0]

thoughts?
  

Useless if you use meaningful names for your variables  attributes.

It may happen that one object attribute refer to an object of the same 
type, but it is quite rare that both can share the same name anyway.


Possible use cases:

1/
car = Car()
car = car.wheel # ???

2/
wheel = Car() # ???
wheel = wheel.wheel # ???

3/
currentCar = Car()
currentCar = currentCar.nextCar

The syntax you prose will be applicable on very little assignements (use 
case 3). I'm not sure it's worth it.


JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[John Bokma]

D'Arcy J.M. Cain da...@druid.net writes:

 On Fri, 30 Apr 2010 09:04:59 -0700 (PDT)
 Jabapyth jabap...@gmail.com wrote:
 foo = Hello world
 foo.=split( )

 Isn't;

 foo = Hello world
 bar = foo.split() # side note - split() splits on whitespace by default

 so much clearer?  Do you really want to see Python turn into Perl?

Oh, boy, there we go again. Can you and your buddies please refrain from
using Perl as a kind of uber-argument? Just write why you think it's
wrong. Bonus points if you can use Python in your arguments.

Why I am asking this is that most Oh, like Perl statements I've seen
the past months were made by people who either haven't used Perl
themselves or have very little skill in the language. This is a Python
group.

On top of that, it's not possible in Perl (heh, no surprise there). The
only thing that comes close is:

for ( $a_very_long_variable_name ) {
 
s/foo/bar/g;
s/baz/woot/g;
s/o+/i/g;
}

Which makes $_ an alias for $a_very and since s/// defaults to $_
this works.

-- 
John Bokma   j3b

Hacking  Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl  Python Development
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Chris Rebert]

On Fri, Apr 30, 2010 at 10:05 AM, John Bokma j...@castleamber.com wrote:
 D'Arcy J.M. Cain da...@druid.net writes:
 On Fri, 30 Apr 2010 09:04:59 -0700 (PDT)
 Jabapyth jabap...@gmail.com wrote:
 foo = Hello world
 foo.=split( )

 Isn't;

 foo = Hello world
 bar = foo.split() # side note - split() splits on whitespace by default

 so much clearer?  Do you really want to see Python turn into Perl?

 Oh, boy, there we go again. Can you and your buddies please refrain from
 using Perl as a kind of uber-argument? Just write why you think it's
 wrong. Bonus points if you can use Python in your arguments.

 Why I am asking this is that most Oh, like Perl statements I've seen
 the past months were made by people who either haven't used Perl
 themselves or have very little skill in the language. This is a Python
 group.

 On top of that, it's not possible in Perl (heh, no surprise there). The
 only thing that comes close is:

Actually/ironically, it does appear to be in Perl 6:

Mutating method call
$obj.=meth
The .= operator does inplace modification of the object on the left.
 -- Synopsis 3: Perl 6 Operators (http://feather.perl6.nl/syn/S03.html)

Cheers,
Chris
--
One phrase: Periodic Table of the Operators
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[D'Arcy J.M. Cain]

On Fri, 30 Apr 2010 12:05:49 -0500
John Bokma j...@castleamber.com wrote:
 D'Arcy J.M. Cain da...@druid.net writes:
  so much clearer?  Do you really want to see Python turn into Perl?
 
 Oh, boy, there we go again. Can you and your buddies please refrain from
 using Perl as a kind of uber-argument? Just write why you think it's
 wrong. Bonus points if you can use Python in your arguments.

I think I was clear that the problem was obfuscation which Perl is very
good at.  Haven't you ever had a Perl programmer show you a snippet of
code and say I bet you can't guess what this does?

 On top of that, it's not possible in Perl (heh, no surprise there). The
 only thing that comes close is:
 
 for ( $a_very_long_variable_name ) {
  
 s/foo/bar/g;
 s/baz/woot/g;
 s/o+/i/g;
 }
 
 Which makes $_ an alias for $a_very and since s/// defaults to $_

I hope that this example wasn't supposed to be a proof of Perl's
readability.

Anyway, you are right.  I just happen to be dealing with some Perl and,
even worse, PHP issues on a new server and I am feeling a little
battered.  I'll be better in a day or two.

By the way, to get back to the original topic, I don't really mind if
this makes it into the language because I won't be forced to use it.

-- 
D'Arcy J.M. Cain da...@druid.net |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Lie Ryan]

On 05/01/10 02:50, Jean-Michel Pichavant wrote:
 Jabapyth wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:
snip
 currentCar = Car()
 currentCar = currentCar.nextCar
 
 The syntax you prose will be applicable on very little assignements (use
 case 3). I'm not sure it's worth it.


And for the last use case, isn't iterator better?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[John Bokma]

Chris Rebert c...@rebertia.com writes:

 On Fri, Apr 30, 2010 at 10:05 AM, John Bokma j...@castleamber.com wrote:

[..]

 On top of that, it's not possible in Perl (heh, no surprise there). The
 only thing that comes close is:

 Actually/ironically, it does appear to be in Perl 6:
 
 Mutating method call
 $obj.=meth
 The .= operator does inplace modification of the object on the left.
  -- Synopsis 3: Perl 6 Operators (http://feather.perl6.nl/syn/S03.html)

I stand correct, thanks.

-- 
John Bokma   j3b

Hacking  Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl  Python Development
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Aahz]

In article 87zl0klvki@castleamber.com,
John Bokma  j...@castleamber.com wrote:

Why I am asking this is that most Oh, like Perl statements I've seen
the past months were made by people who either haven't used Perl
themselves or have very little skill in the language. 

What evidence do you have for your assertion?
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

It is easier to optimize correct code than to correct optimized code.
--Bill Harlan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Brendan Abel]

On Apr 30, 9:04 am, Jabapyth jabap...@gmail.com wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:

 vbl.=func(args)

 this would be equivalent to

 vbl = vbl.func(args)

 example:

 foo = Hello world
 foo.=split( )
 print foo
 # ['Hello', 'world']

 and I guess you could generalize this to

 vbl.=[some text]
 #
 vbl = vbl.[some text]

 e.g.

 temp.=children[0]
 # temp = temp.children[0]

 thoughts?

I tend to use this design pattern occasionally in my code as well:

val = val.func()  PROPOSED:  val .= func()

OR

val = func(val)  PROPOSED: val .= func(?) (not really sure how this
should look)


However, these are the only two use cases I can think of for this
language syntax modification proposal.  The first use case could lead
to namespace issues (if func() exists as a function as well as a
method), and even if the interpreter can choose correctly, reading it
may lead to confusion.  There will be at least some ambiguity in the
second use case (what if func() takes more than one argument, what if
it requires keyword arguments?).  The current implementation is much
more readable (THE guiding principle with python), and doesn't require
any lengthier code than the proposed changes, especially when you
factor in any other syntax changes that would be necessary to handle
the aforementioned ambiguities.

Just my 2 cents. :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Fri, 30 Apr 2010 18:50:46 +0200, Jean-Michel Pichavant wrote:

 Jabapyth wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:

 vbl.=func(args)

 this would be equivalent to

 vbl = vbl.func(args)
[...]
 Useless if you use meaningful names for your variables  attributes.
 
 It may happen that one object attribute refer to an object of the same
 type, but it is quite rare that both can share the same name anyway.

How about these common operations?

my_string = my_string.replace('quite rare', 'very common')
my_string = my_string.upper()
my_string = my_string.strip()

my_dict = my_dict.copy()

Or from decimal, a whole lot of methods that return new decimals, 
including:

to_integral, next_plus, canonical, ln, sqrt, and many others.


But regardless of whether the pattern x = x.method is common or rare, I 
don't like the suggestion, I don't think it's necessary, and because of 
the moratorium it isn't going to happen any time soon even if Guido 
himself suggests it.

-1 for the suggested .= syntactic sugar.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Steven D'Aprano]

On Fri, 30 Apr 2010 12:34:34 -0400, D'Arcy J.M. Cain wrote:

 I assume you mean the former to be analagous to += and friends but I
 am not sure since . isn't an operator.

It's a de facto operator. If you google on python dot operator you will 
find many people who refer to it as such, and attribute lookup can be 
over-ridden at runtime (using __getattribute__, __getattr__, etc.) just 
like operators +, -, * etc.

Also you can do this:

 s = something
 s . upper()
'SOMETHING'
 (s+ else) . upper()
'SOMETHING ELSE'

And even apply the dot operator to floats and ints, although because of 
the ambiguity with floats you need to be clever:

 1.2.is_integer()
False
 4 .numerator
4


However, dot is not a real operator, whatever that means: internally, 
CPython treats it as a delimiter:

http://docs.python.org/reference/lexical_analysis.html#operators


In practice though, I think that's a difference that makes no difference. 
It walks like an operator, it swims like an operator, and it quacks like 
an operator.




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python dot-equals (syntax proposal)

[Patrick Maupin]

On Apr 30, 11:04 am, Jabapyth jabap...@gmail.com wrote:
 At least a few times a day I wish python had the following shortcut
 syntax:

 vbl.=func(args)

 this would be equivalent to

 vbl = vbl.func(args)

 example:

 foo = Hello world
 foo.=split( )
 print foo
 # ['Hello', 'world']

 and I guess you could generalize this to

 vbl.=[some text]
 #
 vbl = vbl.[some text]

 e.g.

 temp.=children[0]
 # temp = temp.children[0]

 thoughts?

First thought:  good luck getting something like this through.
Probably not going to happen, although I do find the idea very
intriguing.

Second thought:  I don't like the proposed syntax at all.

+=, -=, /=, *=, etc.  conceptually (and, if lhs object supports in-
place operator methods, actually) *modify* the lhs object.

Your proposed .= syntax conceptually *replaces* the lhs object
(actually, rebinds the lhs symbol to the new object).

If this were to be deemed worthy of the language, I would think a
better syntax would be something like:

  mystring = .upper()
  mystring = .replace('a', 'b')

etc.

The '=' shows clearly that mystring is being rebound to a new object.

As Steven has shown, '.' functions as an operator, so if this change
were accepted, in reality you would probably be able to write:

mystring = . upper()
mystring=.upper()

or whatever.  But the canonical form would probably be with a space
before the period but not after.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list