On 24 June 2018 at 16:53, Chris Angelico wrote:
> On Sun, Jun 24, 2018 at 4:33 PM, Nick Coghlan wrote:
>> On 24 June 2018 at 15:56, Steven D'Aprano wrote:
>>> On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote:
>>>
Given that PEP 572 *is* proposing implicit comprehension state exp
On Sun, Jun 24, 2018 at 03:56:47PM +1000, Steven D'Aprano wrote:
> There is no consensus that the change to comprehensions was a good thing
> or justified.
On re-reading that, I think its wrong -- it wasn't really what I
intended to say. What I intended to say was, in hindsight, more like:
*De
On 24.06.2018 9:53, Chris Angelico wrote:
On Sun, Jun 24, 2018 at 4:33 PM, Nick Coghlan wrote:
On 24 June 2018 at 15:56, Steven D'Aprano wrote:
On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote:
Given that PEP 572 *is* proposing implicit comprehension state export,
"Implicit" an
On Sun, Jun 24, 2018 at 05:24:12PM +0300, Ivan Pozdeev via Python-Dev wrote:
> An expression is intuitively thought to be self-contained i.e. without
> side effects.
> if I write `a=b+1`, I'm not expecting it to do anything except assigning
> `a'.
a = d.pop(1)
a = d.setdefault(key, 0)
chars_wri
> Is it possible, given that we are not paying for those reports, to
> customize the 'exclude_lines' definitions?
Do you want to exclude python code or C code?
For C code you can mark sections that exclude coverage in lcov
with comments like "LCOV_EXCL_START"
http://ltp.sourceforge.net/coverage/l
A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for
inline assignment, (b) when := is used in a comprehension, set the scope
for the target as if the assignment occurred outside any comprehensions. It
seems we have more support for (a) than for (b) -- at least Nick and Greg
see
On Sun, Jun 24, 2018 at 04:33:38PM +1000, Nick Coghlan wrote:
[...]
> > Making the intentional choice to use an assignment expression is not
> > really "implicit" in any meaningful sense.
>
> No, it's actually implicit: there's an extra "global NAME" or
> "nonlocal NAME" in the equivalent code for
On Sun, Jun 24, 2018 at 09:24:39AM -0700, Guido van Rossum wrote:
> A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for
> inline assignment, (b) when := is used in a comprehension, set the scope
> for the target as if the assignment occurred outside any comprehensions. It
> see
[Guido]
> A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for
inline
> assignment, (b) when := is used in a comprehension, set the scope for the
> target as if the assignment occurred outside any comprehensions. It seems
> we have more support for (a) than for (b) -- at least N
On Mon, Jun 25, 2018 at 4:06 AM, Steven D'Aprano wrote:
>
> Remember, the driving use-case which started this (ever-so-long)
> discussion was the ability to push data into a comprehension and then
> update it on each iteration, something like this:
>
> x = initial_value()
> results = [x :=
This thread started with a request for educator feedback, which I took to
mean observations of student reactions. I've only had the chance to test
the proposal on ~20 students so far, but I'd like the chance to gather more
data for your consideration before the PEP is accepted or rejected.
On Su
On Sun, Jun 24, 2018 at 11:50 AM Steven D'Aprano
wrote:
> [Guido]
> > [...] IIRC (b) originated with Tim.
>
> I'm not sure who came up with the idea first, but as I remember it, the
> first mention of this came in a separate thread on Python-Ideas:
>
> https://mail.python.org/pipermail/python-ide
On Sun, Jun 24, 2018 at 12:03 PM Tim Peters wrote:
> [Guido]
> :> However, [Tim] did post his motivation for (b) on python-ideas, IIRC a
> bit
> > before PyCon; and the main text of the PEP gives a strong motivation
> > (https://www.python.org/dev/peps/pep-0572/#scope-of-the-target).
> Neverthele
Guido van Rossum wrote:
Greg seem to be +0 or better for (a)
Actually, I'm closer to -1 on (a) as well. I don't like := as a
way of getting assignment in an expression. The only thing I would
give a non-negative rating is some form of "where" or "given".
Brief summary of reasons for disliking
On Sun, Jun 24, 2018 at 2:10 PM Chris Angelico wrote:
> On Mon, Jun 25, 2018 at 4:06 AM, Steven D'Aprano
> wrote:
> >
> > Remember, the driving use-case which started this (ever-so-long)
> > discussion was the ability to push data into a comprehension and then
> > update it on each iteration, so
Steven D'Aprano wrote:
You seem to be talking about an implementation which could change in the
future. I'm talking semantics of the proposed language feature.
The way I see it, it's not about implementation details,
it's about having a mental model that's easy to reason
about.
"Comprehensions
Greg Ewing writes:
> Actually, I'm closer to -1 on (a) as well. I don't like := as a
> way of getting assignment in an expression. The only thing I would
> give a non-negative rating is some form of "where" or "given".
+1 to this; ‘:=’ doesn't convey the meaning well. Python's syntax
typically e
On Sun, Jun 24, 2018 at 2:41 PM Michael Selik wrote:
> This thread started with a request for educator feedback, which I took to
> mean observations of student reactions. I've only had the chance to test
> the proposal on ~20 students so far, but I'd like the chance to gather more
> data for your
On Sun, Jun 24, 2018 at 4:57 PM Guido van Rossum wrote:
> On Sun, Jun 24, 2018 at 2:41 PM Michael Selik wrote:
>
>> This thread started with a request for educator feedback, which I took to
>> mean observations of student reactions. I've only had the chance to test
>> the proposal on ~20 student
>
> [Tim]
>>
> . First, the original example I gave would be approximately as well
>> addressed by allowing to declare intended scopes in magically synthesized
>> functions; like (say)
>>
>> p = None # to establish the intended scope of `p`
>> while any( # split across lines just for readability
20 matches
Mail list logo
