On Mon, 23 Apr 2018 00:44:44 -0500
Tim Peters wrote:
>
> Which this alternative expresses directly:
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> return g
>
> That's so Pythonic I could cry ;-)
It looks like C to me. That won't make me cry (I write C++ code daily
these days),
Hello,
I am an intern at Red Hat mentored by Petr Viktorin. As a part of my
internship, I learned the CPython internals and how to contribute
to the CPython interpreter.
As a result, I have prepared PEP 573, which solves some problems
that PEP 489 (Multi-phase extension module initialization) has
[Tim]
>> Which this alternative expresses directly:
>>
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
>>
>> That's so Pythonic I could cry ;-)
[Antoine]
> It looks like C to me. That won't make me cry (I write C++ code daily
> these days), but it's certainly not the same
On Mon, Apr 23, 2018 at 8:28 AM, Antoine Pitrou wrote:
> On Mon, 23 Apr 2018 00:44:44 -0500
> Tim Peters wrote:
> [...]
>
> > if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> > return g
> > That's so Pythonic I could cry ;-)
>
> [...]
>
> The second part, especially, where you use th
On 23.04.2018 17:59, Steve Holden wrote:
While Tim's expression might look (superficially) like C, the
five-line alternative isn't exactly an inspiring example of
Pythonicity, is it?
What about
diff = x - x_base
if diff and gcd(diff, n) > 1:
return gcd(diff, n)
# or
if (x - x_base)
On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote:
> On 23.04.2018 17:59, Steve Holden wrote:
>
>
> While Tim's expression might look (superficially) like C, the five-line
> alternative isn't exactly an inspiring example of Pythonicity, is it?
>
>
> What about
>
> diff = x - x_base
> if diff an
[Sven R. Kunze ]
> What about
>
> diff = x - x_base
> if diff and gcd(diff, n) > 1:
> return gcd(diff, n)
>
> # or
>
> if (x - x_base) and gcd(x - x_base, n) > 1:
> return gcd(x - x_base, n)
>
>
> and have the interpreter handle the optimization, or apply an lru_cache? ;-)
Surely you're jo
Hello,
I just saw this PEP. There is a bit of overlap between PEP 573 and PEP
575 since these both change the calling convention for built-in methods.
In particular, PEP 575 also proposes to add a "defining class" member
(for different reasons). In PEP 575, this is added to the PyCFunction
st
On Mon, 23 Apr 2018 16:59:35 +0100
Steve Holden wrote:
> On Mon, Apr 23, 2018 at 8:28 AM, Antoine Pitrou wrote:
>
> > On Mon, 23 Apr 2018 00:44:44 -0500
> > Tim Peters wrote:
> > [...]
> >
> > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> > > return g
> > > That's so Pythonic
On 04/23/18 14:04, Jeroen Demeyer wrote:
Hello,
I just saw this PEP. There is a bit of overlap between PEP 573 and PEP
575 since these both change the calling convention for built-in methods.
In particular, PEP 575 also proposes to add a "defining class" member
(for different reasons). In PEP
On 04/22/2018 10:44 PM, Tim Peters wrote:
[Guido]
In reality there often are other conditions being applied to the match for
which `if expr as name` is inadequate. The simplest would be something like
if ...:
elif (m := re.match('(.*):(.*)', line)) and m.group(1) == m.group(2):
On 23.04.2018 19:24, Chris Angelico wrote:
On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote:
diff = x - x_base
if diff and gcd(diff, n) > 1:
return gcd(diff, n)
# or
if (x - x_base) and gcd(x - x_base, n) > 1:
return gcd(x - x_base, n)
and have the interpreter handle the optim
On 23.04.2018 19:31, Tim Peters wrote:
Surely you're joking. This is math.gcd(), which is expensive for
multi-thousand bit integers, and the interpreter knows nothing about
it. Adding a cache of _any_ kind (LRU or otherwise) would make it
even slower.
Alright, if that problem is just about perf
On Tue, Apr 24, 2018 at 6:21 AM, Sven R. Kunze wrote:
> On 23.04.2018 19:24, Chris Angelico wrote:
>>
>> On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote:
>>>
>>> diff = x - x_base
>>> if diff and gcd(diff, n) > 1:
>>> return gcd(diff, n)
>>>
>>> # or
>>>
>>> if (x - x_base) and gcd(x -
On Apr 23, 2018, at 13:01, Ethan Furman wrote:
>
> On 04/22/2018 10:44 PM, Tim Peters wrote:
>>
>>
>> I find myself warming more to binding expressions the more I keep them
>> in mind while writing new code.
And I really like the term “binding expressions” because that’s how I think
about thi
On 23.04.2018 22:37, Chris Angelico wrote:
Ah, are you one of those programmers who writes code once and it's
instantly perfect? I apologize, I didn't realize I was in the presence
of a unicorn.
Wow, constructive. Nothing is perfect, but if you don't consider your
surroundings when doing chang
On Tue, Apr 24, 2018 at 7:25 AM, Sven R. Kunze wrote:
> On 23.04.2018 22:37, Chris Angelico wrote:
>>
>> Ah, are you one of those programmers who writes code once and it's
>> instantly perfect? I apologize, I didn't realize I was in the presence
>> of a unicorn.
>
>
> Wow, constructive. Nothing is
On 23.04.2018 23:19, Barry Warsaw wrote:
I also think it effectively solves the switch-statement problem:
if (get_response() as answer) == 'yes':
do_it()
elif answer == 'no':
skip_it()
elif answer == 'maybe'
okay_then()
That’s Pythonic enough for jazz!
Is it just me or since wh
[Tim]
>> Surely you're joking. This is math.gcd(), which is expensive for
>> multi-thousand bit integers, and the interpreter knows nothing about
>> it. Adding a cache of _any_ kind (LRU or otherwise) would make it
>> even slower.
[Sven R. Kunze ]
> Alright, if that problem is just about perform
[Ethan Furman ]
> So I really like being able to make the assignment in the expression, but I
> have a really hard time parsing it with the name first.
>
> ...
>
> On the other hand, if it were using the "as" keyword:
>
> if (x - xbase as diff) and (gcd(diff, n) as g) > 1:
> return g
>
> I woul
On 04/23/2018 03:04 PM, Tim Peters wrote:
[Ethan Furman ]
So I really like being able to make the assignment in the expression, but I
have a really hard time parsing it with the name first.
...
On the other hand, if it were using the "as" keyword:
if (x - xbase as diff) and (gcd(diff, n) as g
Whereas I find it a deal-breaker for 'as'.
On Mon, Apr 23, 2018 at 3:15 PM, Ethan Furman wrote:
> On 04/23/2018 03:04 PM, Tim Peters wrote:
>
>> [Ethan Furman ]
>>
>>> So I really like being able to make the assignment in the expression,
>>> but I
>>> have a really hard time parsing it with the
On Apr 23, 2018, at 18:04, Tim Peters wrote:
> However, against "as" is that its current use in "with" statements
> does something quite different:
>
>with f() as name:
>
> does not bind the result of `f()` to `name`, but the result of
> `f().__enter__()`. Whether that "should be" fatal, I
On 04/23/2018 06:04 PM, Tim Peters wrote:
> However, against "as" is that its current use in "with" statements
> does something quite different:
>
> with f() as name:
>
> does not bind the result of `f()` to `name`, but the result of
> `f().__enter__()`. Whether that "should be" fatal, I do
Using 'as' was debated extensively on python-ideas. I don't like it for
several reasons:
- the semantics are subtly different from all other uses of 'as' in Python;
I'd like to reserve 'as' for "not a plain assignment"
- a short word is easier to miss when skimming code than punctuation
- most oth
On 2018-04-23, 21:34 GMT, Sven R. Kunze wrote:
> Is it just me or since when has the following Python code
> fallen out of favor?
It isn’t just you.
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
… one of the ma
On 4/23/2018 1:01 PM, Ethan Furman wrote:
On 04/22/2018 10:44 PM, Tim Peters wrote:
[Guido]
In reality there often are other conditions being applied to the
match for
which `if expr as name` is inadequate. The simplest would be
something like
if ...:
elif (m := re.match('(.*):(
Tim Peters wrote:
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g
My problem with this is -- how do you read such code out loud?
From my Pascal days I'm used to reading ":=" as "becomes". So
this says:
"If diff becomes x - base and g becomes gcd(diff, n) is
greater t
Sven R. Kunze wrote:
if (x - x_base) and gcd(x - x_base, n) > 1:
return gcd(x - x_base, n)
and have the interpreter handle the optimization, or apply an lru_cache? ;-)
Problem is, there's no way to automatically tell whether
the expressions involved have side effects that are being
relied
[Tim]
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
[Greg Ewing ]
> My problem with this is -- how do you read such code out loud?
In the message in which I first gave that example:
if the diff isn't 0 and gcd(diff, n) > 1, return the gcd.
That's how I _thought_
On Mon, Apr 23, 2018 at 03:36:10PM -0700, Guido van Rossum wrote:
> Using 'as' was debated extensively on python-ideas. I don't like it for
> several reasons:
[...]
For what it is worth, I was one of the original proponents of the "as"
syntax, but at this point I am no longer going to argue for i
On Mon, Apr 23, 2018 at 4:54 PM, Greg Ewing wrote:
> Tim Peters wrote:
>
>> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>> return g
>
>
> My problem with this is -- how do you read such code out loud?
It could be--
"if diff, which we let equal x - x_base, and g, which ..." or
"if di
Tim Peters writes:
> Regardless, Guido has already said "as" is DOA (Dead On Arrival)
> (illustrating that it's also common enough in English to give a short
> name before its long-winded meaning ;-) ).
The parens above are a gloss on a well-known acronym for those who
have not encountered it
[Steve Holden ]
>> ...
>> The assignment expression seems like a vary natural way to introduce
>> variables of limited (controlled?) scope, [...]
[Antoine Pitrou ]
> AFAIU, the scope isn't limited to the "if" block, it's a regular local
> variable. I might have misread.
You're right about the cu
On Tue, 24 Apr 2018 01:06:30 -0500
Tim Peters wrote:
>
> > - does it make Python easier to learn and teach?
>
> By whom? Almost no addition has ever made a language easier to learn
> for raw beginners: every addition is something they eventually need
> to learn. We could make Python easier
On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote:
> On Tue, 24 Apr 2018 01:06:30 -0500
> Tim Peters wrote:
>>
>> > - does it make Python easier to learn and teach?
>>
>> By whom? Almost no addition has ever made a language easier to learn
>> for raw beginners: every addition is something t
[Antoine]
>>> - does it make Python easier to learn and teach?
[Tim]
>> By whom? Almost no addition has ever made a language easier to learn
>> for raw beginners: every addition is something they eventually need
>> to learn. We could make Python easier to learn for beginners by
>> throwing out
37 matches
Mail list logo
