On Tue, Aug 27, 2013 at 2:39 AM, Kevin Ballard wrote:
[snip]
> My understanding of Python's GIL is that += is indeed atomic because the GIL
> only locks/unlocks around statements (though I don't believe this is
> intentional). Though this certainly isn't the case for C/C++.
No, that's incorrect
>On Mon, Aug 26, 2013 at 8:39 PM, Kevin Ballard wrote:
> On Aug 26, 2013, at 2:46 PM, Daniel Micay wrote:
>
>> On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 wrote:
>>> I also think Python's argumented assignments are fine and both a += b vs a +
>>> b should behave differently. I personally read a +=
On Aug 26, 2013, at 2:46 PM, Daniel Micay wrote:
> On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 wrote:
>> I also think Python's argumented assignments are fine and both a += b vs a +
>> b should behave differently. I personally read a += b as an atomic,
>> thread-safe operation whereas a + b isn't
2013/8/26 Daniel Micay
> On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 wrote:
> > I also think Python's argumented assignments are fine and both a += b vs
> a +
> > b should behave differently. I personally read a += b as an atomic,
> > thread-safe operation whereas a + b isn't and I beleive that's
On Mon, Aug 26, 2013 at 5:36 PM, Flaper87 wrote:
> I also think Python's argumented assignments are fine and both a += b vs a +
> b should behave differently. I personally read a += b as an atomic,
> thread-safe operation whereas a + b isn't and I beleive that's the way it
> shoud be. Expanding a
2013/8/26 Flaper87
> argumented
augmented* T_T
--
Flavio (@flaper87) Percoco
http://www.flaper87.org
http://github.com/FlaPer87
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
2013/8/25 Armin Ronacher
> Hi,
>
>
> On 23/08/2013 19:36, Graydon Hoare wrote:
>
>> Could you say more (perhaps more constructively)? I believe we have
>> every intention to support these sorts of overloads longer-term; we
>> removed the previous support only because it wasn't done terribly well.
Hi,
On 23/08/2013 19:36, Graydon Hoare wrote:
Could you say more (perhaps more constructively)? I believe we have
every intention to support these sorts of overloads longer-term; we
removed the previous support only because it wasn't done terribly well.
I think augmented assignments in Python ar
On Fri, Aug 23, 2013 at 12:21 PM, Graydon Hoare wrote:
> On 13-08-23 12:16 PM, Simon Sapin wrote:
> > Le 23/08/2013 19:47, Matthieu Monrocq a écrit :
> >> The most trivial mistake is to have `+=` and `+` defined so that `a +=
> >> 5` has a different result than `a = a + 5`
> >
> > Would it work t
On Fri, Aug 23, 2013 at 2:28 PM, Masklinn wrote:
> For the record, I think augmented assignments are a terrible ideas and one of
> the worst features of python.
rust-dev is probably not the right place for this sort of
conversation; several points of the code of conduct
(https://github.com/mozil
On Fri, Aug 23, 2013 at 8:36 PM, Graydon Hoare wrote:
> On 13-08-23 11:28 AM, Masklinn wrote:
>
>> For the record, I think augmented assignments are a terrible ideas and one
>> of the worst features of python.
>
> Could you say more (perhaps more constructively)? I believe we have
> every intenti
On 13-08-23 12:16 PM, Simon Sapin wrote:
> Le 23/08/2013 19:47, Matthieu Monrocq a écrit :
>> The most trivial mistake is to have `+=` and `+` defined so that `a +=
>> 5` has a different result than `a = a + 5`
>
> Would it work to make `a += b` always expand to `a = a + b`, and have
> that not be
Le 23/08/2013 19:47, Matthieu Monrocq a écrit :
The most trivial mistake is to have `+=` and `+` defined so that `a +=
5` has a different result than `a = a + 5`
Would it work to make `a += b` always expand to `a = a + b`, and have
that not be overridable? Or am I missing something else?
--
ten broken) concepts.
As for this specific case, I think allowing overloading += makes sense, but I
don't feel strongly.
keegan
- Original Message -
From: "Artem Egorkine"
To: "Masklinn"
Cc: rust-dev@mozilla.org
Sent: Friday, August 23, 2013 11:52:49 AM
Augmented assignments are not unique to python. They are found in C, Java,
Perl, Go, Ruby, JavaScript etc. One could argue that if they were so
terrible, they would never have made it to so many programming languages
On Aug 23, 2013 9:28 PM, "Masklinn" wrote:
>
> On 23 août 2013, at 12:44, C
On Fri, Aug 23, 2013 at 8:36 PM, Graydon Hoare wrote:
> On 13-08-23 11:28 AM, Masklinn wrote:
>
> > For the record, I think augmented assignments are a terrible ideas and
> one of the worst features of python.
>
> Could you say more (perhaps more constructively)? I believe we have
> every intenti
On 13-08-23 11:28 AM, Masklinn wrote:
> For the record, I think augmented assignments are a terrible ideas and one of
> the worst features of python.
Could you say more (perhaps more constructively)? I believe we have
every intention to support these sorts of overloads longer-term; we
removed t
On 23 août 2013, at 12:44, Chris Morgan wrote:
> https://github.com/mozilla/rust/issues/5992
>
> (Coming from a Python background I know the concept as augmented
> assignment; they are also known as assignment operators. Or just +=,
> ^=, <<= and the like.)
>
> I want augmented assignment in Ru
https://github.com/mozilla/rust/issues/5992
(Coming from a Python background I know the concept as augmented
assignment; they are also known as assignment operators. Or just +=,
^=, <<= and the like.)
I want augmented assignment in Rust for all types, so I had a crack at
implementing this. I have
19 matches
Mail list logo
