On Fri, Sep 28, 2018 at 6:56 PM Jonathan Fine wrote:
> Finally, I note
>
> >>> a = 2
> >>> a **= 3
> >>> a
> 8
>
? Yes? That's what 2 ** 3 is, so that's what I would expect.
All other augmented assignment operators take an assignment target on
the left and a (single) value on the right.
ChrisA
Summary: I recast an example in a more abstract form.
Steve D'Aprano wrote:
> Think about a more complex assignment:
>text .= encode(spam) + str(eggs)
I find this example instructive. I hope the following is also instructive:
$ python3
>>> obj += incr
NameError: name 'obj' is not defined
On Fri, Sep 28, 2018 at 05:34:58PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >Think about a more complex assignment:
> >
> >text .= encode(spam) + str(eggs)
>
> I think the only sane thing would be to disallow that, and
> require the RHS to have the form of a function call, which is
I had the number 4 in mind
Though I think your idea is way better, as it's more flexible and less
confusing
On Fri, Sep 28, 2018, 10:33 Brice Parent wrote:
>
> Le 27/09/2018 à 12:48, Ken Hilton a écrit :
>
> Hi Jasper,
> This seems like a great idea! It looks so much cleaner, too.
>
> Would
Le 27/09/2018 à 12:48, Ken Hilton a écrit :
Hi Jasper,
This seems like a great idea! It looks so much cleaner, too.
Would there be a dunder method handling this? Or since it's explicitly
just a syntax for "obj = obj.method()" is that not necessary?
My only qualm is that this might get PHP
Steven D'Aprano wrote:
Think about a more complex assignment:
text .= encode(spam) + str(eggs)
I think the only sane thing would be to disallow that, and
require the RHS to have the form of a function call, which is
always interpreted as a method of the LHS.
--
Greg
On 2018-09-27 03:48, Ken Hilton wrote:
Would there be a dunder method handling this? Or since it's explicitly
just a syntax for "obj = obj.method()" is that not necessary?
My only qualm is that this might get PHP users confused; that's really
not an issue, though, since Python is not PHP.
I'm
On Thu, Sep 27, 2018 at 09:47:42PM -0400, James Lu wrote:
> > I agree that this adds ambiguity where we can't be sure whether text .=
> > encode('utf-8') is referring to the function or the method. We can infer
> > that it *ought* to be the method, and maybe even add a rule to force
> > that,
This seems like a fairly terrible idea. -100 from me.
Python simply does not tends to chain methods for mutation of objects. A
few libraries—e.g. Pandas—do this, but in those cases actual chaining is
more idiomatic.
This is very different from '+=' or '*=' or even '|=' where you pretty much
On Thu, Sep 27, 2018 at 10:44:38PM +0300, Taavi Eomäe wrote:
> > Do you see how this creates an ambiguous situation?
>
> Name shadowing could create such ambiguous situations anyways even without
> the new operator?
How? Can you give an example?
Normally, there is no way for a bare name to
> As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are
As I see it, you are mixing very different things. Augmented operators in
Python work on objects, generally trying to mutate them in-place. So
usually after these operations you have the same object (with the same
type, with the same name and etc.) as before these operations. Of course
there are
> items = ["foo", "bar", "quux"]
> items[randrange(3)] .= upper()
>
> Is this equivalent to:
>
> items[randrange(3)] = items[randrange(3)].upper()
>
> ? That would call randrange twice, potentially grabbing one element
> and dropping it into another slot. If it isn't equivalent to that, how
> is
On Wed, Sep 26, 2018 at 9:14 PM Jasper Rebane wrote:
> When using Python, I find myself often using assignment operators, like 'a +=
> 1' instead of 'a = a + 1', which saves me a lot of time and hassle
>
> Unfortunately, this doesn't apply to methods, thus we have to write code like
> this:
>
> Do you see how this creates an ambiguous situation?
Name shadowing could create such ambiguous situations anyways even without
the new operator?
> In my opinion, it goes against the notion that explicit is better than
implicit.
By that logic all operation-assign operations violate that rule
On 2018-09-27 14:13, Calvin Spealman wrote:
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation?
I believe Calvin is right. .= Assumes that every function returns a value or
perhaps implies purity. In my opinion, it goes against the notion that explicit
is better than implicit.
Stelios Tymvios
> On 27 Sep 2018, at 4:13 PM, Calvin Spealman wrote:
>
> Absolutely -1 on this. Consider the
Absolutely -1 on this. Consider the following example:
def encode(s, *args):
"""Force UTF 8 no matter what!"""
return s.encode('utf8')
text = "Hello, there!"
text .= encode('latin1')
Do you see how this creates an ambiguous situation? Implicit attribute
lookup like this is really
Hi Jasper,
This seems like a great idea! It looks so much cleaner, too.
Would there be a dunder method handling this? Or since it's explicitly just
a syntax for "obj = obj.method()" is that not necessary?
My only qualm is that this might get PHP users confused; that's really not
an issue, though,
Hi,
When using Python, I find myself often using assignment operators, like 'a
+= 1' instead of 'a = a + 1', which saves me a lot of time and hassle
Unfortunately, this doesn't apply to methods, thus we have to write code
like this:
text = "foo"
text = text.replace("foo","bar")
# "bar"
I
20 matches
Mail list logo
