On Fri, Apr 20, 2018 at 4:32 PM, Robert Smallshire wrote:
> If you restrict the idea to 'if' and 'while', Why not render this using the
> existing 'as' form for binding names, already used with 'except' and 'with':
>
> while learner.get(static_hint) as points:
> learner.feed(f(points))
On Fri, Apr 20, 2018 at 1:30 PM, Stephen J. Turnbull
wrote:
> Christoph Groth writes:
>
> > Wouldn't it be a pity not to liberate assignments from their boring
> > statement existence?
>
> Maybe not. While it would be nice to solve the loop-and-a-half
> "problem" and the loop variable initializ
If you restrict the idea to 'if' and 'while', Why not render this using the
existing 'as' form for binding names, already used with 'except' and 'with':
while learner.get(static_hint) as points:
learner.feed(f(points))
The equivalent for 'if' helps with the regex matching case:
i
On Fri, Apr 20, 2018 at 2:45 PM, Dmitry Malinovsky wrote:
> Hello Chris, and thank you for working on this PEP!
>
> What do you think about using variable type hints with this syntax?
> I tried to search through python-dev and couldn't find a single post
> discussing that question.
> If I missed i
> On Apr 19, 2018, at 4:27 PM, Christoph Groth wrote:
> def sync_runner(learner, f, static_hint):
>while True:
>points = learner.get(static_hint)
>if not points:
>break
>learner.feed(f(points))
>
>
>
> With assignment expressions the body of the above fun
Hello Chris, and thank you for working on this PEP!
What do you think about using variable type hints with this syntax?
I tried to search through python-dev and couldn't find a single post
discussing that question.
If I missed it somehow, could you please include its conclusions into the PEP?
For
Christoph Groth writes:
> Wouldn't it be a pity not to liberate assignments from their boring
> statement existence?
Maybe not. While it would be nice to solve the loop-and-a-half
"problem" and the loop variable initialization "problem" (not everyone
agrees these are even problems, especially
Working on the reference implementation for PEP 572 is turning out to
be a massive time sink, both on my personal schedule and on the PEP's
discussion. I can't just hold off all discussion on a topic until I
figure out whether something is possible or not, because that could
take me several days, e
I'd like to break a lance for PEP 572.
I read that in the bad old days Python used to have a "=" operator in
expressions that had the meaning of today's "==". Perhaps there were
other reasons, but this choice alone meant that assignment (that was
using the same token) could not be made an express
On Thu, Apr 19, 2018 at 5:45 AM, Nick Coghlan wrote:
> * for the while loop use case, I think my discussion with Tim about
> tuple unpacking shows that the loop-and-a-half construct won't be
> going anywhere, so users would still end up needing to learn both
> forms (even for new code)
>
well, y
On 19 April 2018 at 02:38, Brett Cannon wrote:
> I'm also -1.
>
> I understand the usefulness of the construct in languages where block scopes
> make having this kind of expression assignment in e.g. an 'if' guard useful.
> But for Python and it's LGB scoping -- although I think we need to add an
On 19 April 2018 at 02:18, Guido van Rossum wrote:
> On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico wrote:
>>
>> On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum
>> wrote:
>> 2) Genexps will eagerly evaluate a lookup if it happens to be the same
>> name as an internal iteration variable.
>
>
12 matches
Mail list logo
