On 09/07/18 08:26, Matěj Cepl wrote:
On 2018-07-07, 15:48 GMT, Guido van Rossum wrote:
if validate(name := re.search(pattern, line).group(1)):
return name
Except there is no error handling for situations when
re.search() returns None, so one shouldn't use it anyway (most
of the
On Tue, Jul 10, 2018 at 2:20 AM, Paddy McCarthy wrote:
>
>
> On Sat, 7 Jul 2018 at 16:50, Guido van Rossum wrote:
>>
>> This seems more suitable for a style guide.
>
>
> Which would be good enough, if the automatic checkers were improved to flag
> such poor use of ':='..
>
> Would that be
On Sat, 7 Jul 2018 at 16:50, Guido van Rossum wrote:
> This seems more suitable for a style guide.
>
Which would be good enough, if the automatic checkers were improved to
flag such poor use of ':='..
Would that be possible?
___
Python-Dev mailing
On Mon, Jul 9, 2018 at 8:54 AM, Tim Peters wrote:
> [Eric V. Smith]
>>
>> > there is at least one place
>>
>> > where the grammar does forbid you from doing something that would
>> > otherwise make be allowable: decorators.
>
>
> [Greg Ewing]
>>
>> And that was a controversial issue at the time.
On 2018-07-07, 15:48 GMT, Guido van Rossum wrote:
> if validate(name := re.search(pattern, line).group(1)):
> return name
Except there is no error handling for situations when
re.search() returns None, so one shouldn't use it anyway (most
of the time). Which seems to me like another
[Eric V. Smith]
> > there is at least one place
> where the grammar does forbid you from doing something that would
> > otherwise make be allowable: decorators.
>
[Greg Ewing]
> And that was a controversial issue at the time. I don't remember
there being much of an objective argument for the
Eric V. Smith wrote:
there is at least one place
where the grammar does forbid you from doing something that would
otherwise make be allowable: decorators.
And that was a controversial issue at the time. I don't remember
there being much of an objective argument for the restriction --
it was
Fair enough. I will. Sorry for the extra pressure at this particular stage.
On Mon, 9 Jul 2018 at 00:06, Guido van Rossum wrote:
> Since you CC'ed me explicitly I feel compelled to respond. I have read
> your reasoning, and I simply don't agree with it. A few months ago I would
> have happily
Since you CC'ed me explicitly I feel compelled to respond. I have read your
reasoning, and I simply don't agree with it. A few months ago I would have
happily explained why (there is a reason) but given the endless debate
we've already seen I am simply too tired for another long email. Please
give
On Mon, Jul 9, 2018 at 7:27 AM, Giampaolo Rodola' wrote:
> 5) It has no keyword argument correspondence. If foo(x := 1) is
> allowed then why this one is not?
> >>> foo(x=(x := 1))
> (I don't think it should BTW: it's not pretty)
Actually it is. Nothing wrong with that. It assigns to 'x' in
On Sun, Jul 8, 2018 at 7:24 PM Chris Angelico wrote:
>
> On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote:
> >
> >
> > On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote:
> >>
> >> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola'
> >> wrote:
> >>>
> >>> [...]
> >>> I find that (space
I'm sure that only 1 or 2 people cares about my opinion on this, but I will
say that PEP 572 is taking one of my least favorite features of C/C++ and
adding it to Python. About the only good thing I can say about it is that
it might make some things more convenient to write. Worse to read, worse
On 7/8/2018 1:59 PM, Chris Angelico wrote:
On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote:
I agree with Chris in this case. That said, there is at least one place
where the grammar does forbid you from doing something that would otherwise
make be allowable: decorators.
@lookup[0]
On Mon, Jul 9, 2018 at 3:55 AM, Eric V. Smith wrote:
> I agree with Chris in this case. That said, there is at least one place
> where the grammar does forbid you from doing something that would otherwise
> make be allowable: decorators.
>
@lookup[0]
> File "", line 1
> @lookup[0]
>
On 7/8/2018 1:23 PM, Chris Angelico wrote:
On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote:
On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote:
But the PEP 8 spellings are
foo(x=1)
and
f(x := 1).
The extra spacing makes it obvious that this isn't a regular named
The case I find more reasonable is assignment in earlier arguments:
z = something ()
w = myfun(x := get_data(), y=calculate(x, z))
I would probably recommend against that in code review, but it's not
absurdly obfuscated.
On Sun, Jul 8, 2018, 1:15 PM Giampaolo Rodola' wrote:
>
>
> On Sun, Jul
On Mon, Jul 9, 2018 at 3:14 AM, Giampaolo Rodola' wrote:
>
>
> On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote:
>>
>> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola'
>> wrote:
>>>
>>> [...]
>>> I find that (space between the parentheses of a function call statement)
>>> too unnatural as a
On Sun, Jul 8, 2018 at 6:45 PM Steve Holden wrote:
> On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola'
> wrote:
>
>> [...]
>> I find that (space between the parentheses of a function call statement)
>> too unnatural as a place where to put an assignment. It is not even
>> "guarded" by a
On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola'
wrote:
> [...]
> I find that (space between the parentheses of a function call statement)
> too unnatural as a place where to put an assignment. It is not even
> "guarded" by a keyword like "if" or "while" which can help as indicators
> that
On 7/8/2018 5:41 AM, Giampaolo Rodola' wrote:
As for "assert" what I'm concern about is the proliferation of things
like this:
class Foo:
def __init__(self):
assert self.x := fun1()
assert self.y := fun2()
assert self.z := fun3()
When I look
On Sat, Jul 7, 2018 at 5:48 PM Guido van Rossum wrote:
> Enforcing such restrictions in the grammar would actually be complicated,
> due to nesting -- but even if it wasn't, I wouldn't want to, as I don't
> want to limit future generations to only the benefits of the new construct
> that we can
>
> [Tim]
> > When I was staring at my code, I never mentioned the very first
> > plausible use I bumped into (in code I was actively working on at the
> time):
> >
> > while not probable_prime(p := randrange(lo, hi)):
> > pass
> > # and now `p` is likely a random prime in range
>
{Terry
On 2018-07-07 06:09, Giampaolo Rodola' wrote:
I initially found myself disliking the idea as a whole but
https://github.com/python/cpython/pull/8122 made me (and others) reconsider it
quite a bit (see: https://twitter.com/grodola/status/1015251302350245888).
PR-8122 clearly shows an
On 7/7/2018 12:53 PM, Tim Peters wrote:
[Guido]
...
As to why you might want to use := in a function call, I could
imagine writing
if validate(name := re.search(pattern, line).group(1)):
return name
If name has to be non-blank to pass validate, one can avoid
[Guido]
> ...
> As to why you might want to use := in a function call, I could imagine
> writing
>
> if validate(name := re.search(pattern, line).group(1)):
> return name
>
When I was staring at my code, I never mentioned the very first plausible
use I bumped into (in code I was
This seems more suitable for a style guide.
Enforcing such restrictions in the grammar would actually be complicated,
due to nesting -- but even if it wasn't, I wouldn't want to, as I don't
want to limit future generations to only the benefits of the new construct
that we can now come up with.
On Sat, Jul 7, 2018 at 11:09 PM, Giampaolo Rodola' wrote:
> To me this looks like the perfect example of where this functionality can be
> abused. Also, I'm not clear what PEP-572 intend to do about "all other
> places". E.g. should these cases be allowed? (IMO no)
>
> >>> yield x := 3
>
Sorry in advance for opening yet another topic about PEP-572. With PEP-572
being officially accepted I know debating its inclusion in the language is
a useless exercise at this point, but since it's still in "draft" status I
would like to express my opinion as I think this is a feature which can
28 matches
Mail list logo
