Python dot-equals (syntax proposal)
in [Python]
|
Prev: Python daemonisation with python-daemon
Next: External Hashing [was Re: matching strings in a large set of strings]
From: John Bokma on 30 Apr 2010 14:18 Chris Rebert <clp2(a)rebertia.com> writes: > On Fri, Apr 30, 2010 at 10:05 AM, John Bokma <john(a)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
From: Aahz on 30 Apr 2010 15:02 In article <87zl0klvki.fsf(a)castleamber.com>, John Bokma <john(a)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 (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
From: Brendan Abel on 30 Apr 2010 16:09 On Apr 30, 9:04 am, Jabapyth <jabap...(a)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. :)
From: Steven D'Aprano on 30 Apr 2010 20:58 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
From: Steven D'Aprano on 30 Apr 2010 21:16
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 |