>
> [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
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
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
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
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
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
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 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
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
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 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 :=
[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 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
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
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
> 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
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
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 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 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
20 matches
Mail list logo
