From: John Bokma on
Chris Rebert <clp2(a)> writes:

> On Fri, Apr 30, 2010 at 10:05 AM, John Bokma <john(a)> 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 (

I stand correct, thanks.

John Bokma j3b

Hacking & Hiking in Mexico - - Perl & Python Development
From: Aahz on
In article <87zl0klvki.fsf(a)>,
John Bokma <john(a)> 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 (aahz(a) <*>

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
From: Brendan Abel on
On Apr 30, 9:04 am, Jabapyth <jabap...(a)> 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()


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. :)
From: Steven D'Aprano on
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,

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.

From: Steven D'Aprano on
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()
>>> (s+" else") . upper()

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()
>>> 4 .numerator

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

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.