On 15 November 2016 at 04:39, Yury Selivanov wrote:
> On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
>>
>> What about making "run" an instance method of coroutines?
>
> That would require coroutines to be aware of the loop that is running them.
> Not having them aware of that is what makes the design
>
> No, the conditional branching would be based on exists.__bool__ (or,
> in the current working draft, is_not_none.__bool__), and that would be
> "0 is not None", which would be True and hence short-circuit.
>
>
> `__then__` is responsible for *unwrapping* the original value from the
> circuit b
2016-11-14 19:40 GMT-08:00 MRAB :
> On 2016-11-15 02:59, Matthias welp wrote:
> [snip]
>
> e.g. if you use 'a = a + 1', python under the hood interprets it as
>> 'a = a.__add__(1)', but if you use 'a += 1' it uses 'a.__iadd__(1)'.
>>
>
> FTR, 'a += 1' is interpreted as 'a = a.__iadd__(1)'.
Or to
On 2016-11-15 02:59, Matthias welp wrote:
[snip]
e.g. if you use 'a = a + 1', python under the hood interprets it as
'a = a.__add__(1)', but if you use 'a += 1' it uses 'a.__iadd__(1)'.
FTR, 'a += 1' is interpreted as 'a = a.__iadd__(1)'.
___
Python
>> For a mutable class, A = A + something is fundamentally different from
>> A += something.
>>
>> Paul
> Ok I am calmed down already.
> But how do you jump to lists already? I started an example with integers.
> I just want to increment an integer and I don't want to see any += in my code,
> it s
It would be nice if
coalesce(EXPR1, EXPR2, EXPR3)
Evaluated the N+1 argument only if the Nth evaluated to None. Of course
this may break the general patterns in the Python language. Maybe we can
fake it by wrapping the expressions in lambdas:
coalesce(lambda: EXPR1(), lambda EXPR2(
On 15 November 2016 at 00:34, Paul Moore wrote:
> On 14 November 2016 at 22:13, Mikhail V wrote:
>>> we don't want A = A + 1 to be the same as A += 1 "
>>
>> This sounds quite frustrating for me, what else could this be but A += 1?
>> Would I want a copy with same name? How that will make sense?
On 14 November 2016 at 22:13, Mikhail V wrote:
>> we don't want A = A + 1 to be the same as A += 1 "
>
> This sounds quite frustrating for me, what else could this be but A += 1?
> Would I want a copy with same name? How that will make sense?
>>> A = [1,2,3]
>>> B = A
>>> A = A + [1]
>>> A
[1, 2,
This is just a matter of understanding the actual semantics of Python,
which is not the same as other languages such as C. In Python the
"assignment operator" is a way of *binding a value*. So writing:
a = some_expression
Is ALWAYS and ONLY binding the value of `some_expression` to the name `a
On 14 November 2016 at 21:52, Todd wrote:
>> I can understand you good. But imagine, if Numpy would allow you to
>> simply write:
>> A = A + 1
>> Which would bring you directly to same internal procedure as A += 1.
>> So it does not currently, why?
>
>
> First, because the language doesn't allow
On Mon, Nov 14, 2016 at 3:42 PM, Mikhail V wrote:
> On 14 November 2016 at 19:57, Nick Timkovich
> wrote:
> > Currently, Numpy takes advantage of __iadd__ and friends by performing
> the
> > operation in-place; there is no copying or other object created. Numpy is
> > very thinly C, for better a
On 11/14/2016 03:42 PM, Mikhail V wrote:
On 14 November 2016 at 19:57, Nick Timkovich wrote:
I can understand you good. But imagine, if Numpy would allow you to
simply write:
A = A + 1
Which would bring you directly to same internal procedure as A += 1.
So it does not currently, why?
I've teste
On 14 November 2016 at 19:57, Nick Timkovich wrote:
> Currently, Numpy takes advantage of __iadd__ and friends by performing the
> operation in-place; there is no copying or other object created. Numpy is
> very thinly C, for better and worse (which is also likely where the +=
> syntax came from).
On Mon, Nov 14, 2016 at 1:21 PM, Mikhail V wrote:
> On 14 November 2016 at 12:16, Steven D'Aprano wrote:
> > On Mon, Nov 14, 2016 at 01:19:30AM +0100, Mikhail V wrote:
> >
> > [...]
> >> >> A good syntax example:
> >> >>
> >> >> a = sum (a, c)
> >
> > There is a reason why mathematicians and acc
Currently, Numpy takes advantage of __iadd__ and friends by performing the
operation in-place; there is no copying or other object created. Numpy is
very thinly C, for better and worse (which is also likely where the +=
syntax came from). If you're doing vast amounts of numeric computation, it
quic
What about making "run" an instance method of coroutines?
On 14.11.2016 19:30, Yury Selivanov wrote:
Hi Guido,
On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which
would be
something akin to
def run(coro):
return get_event_loo
On 2016-11-14 1:35 PM, Sven R. Kunze wrote:
What about making "run" an instance method of coroutines?
That would require coroutines to be aware of the loop that is running
them. Not having them aware of that is what makes the design simple and
allows alternatives to asyncio.
All in all
On 14 November 2016 at 12:16, Steven D'Aprano wrote:
> On Mon, Nov 14, 2016 at 01:19:30AM +0100, Mikhail V wrote:
>
> [...]
>> >> A good syntax example:
>> >>
>> >> a = sum (a, c)
>
> There is a reason why mathematicians and accountants use symbols as a
> compact notation for common functions, ins
Hi Guido,
On 2016-11-12 4:24 PM, Guido van Rossum wrote:
I think there's a plan to add a run() function to asyncio, which would be
something akin to
def run(coro):
return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Please see https://github.com/python/a
On 14 November 2016 at 19:01, Ryan Fox wrote:
> (Hi, I'm a first-time poster. I was inspired by Raymond Hettinger's keynote
> at PyCon CA to look at new PEPs and comment on them. Hopefully, I'm not
> committing any faux-pas in my post!)
>
> 1) I don't think this proposal sufficiently handles falsy
On 13 November 2016 at 21:25, Ivan Levkivskyi wrote:
> This reminds me @ vs .dot() for matrix multiplication a bit. Pandas has
> IndexSlicer, NumPy has index_exp, etc. I think it would be nice to have a
> simple common way to express this.
> But here we have an additional ingredient -- generic typ
On Mon, Nov 14, 2016 at 01:19:30AM +0100, Mikhail V wrote:
[...]
> >> A good syntax example:
> >>
> >> a = sum (a, c)
There is a reason why mathematicians and accountants use symbols as a
compact notation for common functions, instead of purely functional
notation.
Here is a real-world example
(Hi, I'm a first-time poster. I was inspired by Raymond Hettinger's keynote
at PyCon CA to look at new PEPs and comment on them. Hopefully, I'm not
committing any faux-pas in my post!)
1) I don't think this proposal sufficiently handles falsy values.
What is the expected value of x in the followi
23 matches
Mail list logo
