On 21 April 2018 at 07:33, Tim Peters wrote:
> I expected that, given that expressions "naturally nest", chained
> targets could still be specified:
>
> a := b := c:= 5
>
> but since they're all plain names there's no way to tell whether the
> bindings occur "left to right" or "right to left"
On Sat, Apr 21, 2018 at 11:38 AM, Anthony Flury via Python-Dev
wrote:
> I am entirely new to this list, but if I can I would like share my comments
> :
>
> * I do think this proposal := has merit in my
>opinion; it does make some code more readable.
>
> * I think readability is only improv
[Tim]
>> And I'll take this opportunity to repeat the key point for me: I
>> tried hard, but never found a single case based on staring at real
>> code where allowing _fancier_ (than "plain name") targets would be a
>> real improvement. In every case I thought it _might_ help, it turned
>> out th
As an experiment we have gotten an instance of Zulip running for Python's
development at https://python.zulipchat.com (IOW this is for discussing the
development *of* Python only*)*. As Guido has put it you can view Zulip
like "hyper-interactive email" as we have streams corresponding to
equivalent
[Chris Angelico ]
> I don't see much value in restricting the assignment target to names
> only, but if that's what it takes, it can be restricted, at least
> initially.
I believe this point was made most clearly before by Terry Reedy, but
it bears repeating :-) This is from the PEP's motivation:
I am entirely new to this list, but if I can I would like share my
comments :
* I do think this proposal := has merit in my
opinion; it does make some code more readable.
* I think readability is only improved if :
* target is restricted to a simple name - I don't see a benefit in
On Sat, Apr 21, 2018 at 8:07 AM, Mike Miller wrote:
> On 2018-04-20 14:59, Jelle Zijlstra wrote:
>> In other words, the with statement would continue to require an as
>> clause
>> outside of the parentheses. A double name binding doesn't seem very
>> useful
>> however.
>>
>> The with
On 2018-04-20 22:33, Tim Peters wrote:
[snip]
And I'll take this opportunity to repeat the key point for me: I
tried hard, but never found a single case based on staring at real
code where allowing _fancier_ (than "plain name") targets would be a
real improvement. In every case I thought it _m
On 2018-04-20 14:59, Jelle Zijlstra wrote:
> In other words, the with statement would continue to require an as clause
> outside of the parentheses. A double name binding doesn't seem very
useful
> however.
>
> The with statement does not require an as clause.
Sorry, more precisely
2018-04-20 14:54 GMT-07:00 Mike Miller :
>
> In other words, the with statement would continue to require an as clause
> outside of the parentheses. A double name binding doesn't seem very useful
> however.
>
> The with statement does not require an as clause.
On 2018-04-20 12:43, Chris Angelico wrote:
> Except that that's now a feature of expressions, NOT of the loop
> construct. And then you're left with: why not permit this everywhere?
Sorry, I didn't understand. Didn't mean to imply it couldn't be used
everywhere.
> What would these mean?
My e
[Guido, about
g(items[idx] := idx := f())
]
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := ".
I was "successful" only in that the two of us agreed that would be far
less disruptive, and quite pos
On Fri, Apr 20, 2018 at 2:04 PM, Chris Angelico wrote:
> On Sat, Apr 21, 2018 at 6:59 AM, Guido van Rossum
> wrote:
> > Does the PEP currently propose to *allow* that horrible example? I
> thought
> > Tim Peters successfully pleaded to *only* allow a single "NAME :=
> ".
> > You don't have to im
On Sat, Apr 21, 2018 at 6:59 AM, Guido van Rossum wrote:
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := ".
> You don't have to implement this restriction -- we know it's possible to
> implement, and i
Does the PEP currently propose to *allow* that horrible example? I thought
Tim Peters successfully pleaded to *only* allow a single "NAME := ".
You don't have to implement this restriction -- we know it's possible to
implement, and if specifying this alone were to pull enough people from -1
to +0 t
On Sat, Apr 21, 2018 at 6:04 AM, David Mertz wrote:
> It's horrors like this:
>
> g(items[idx] := idx := f())
>
> That make me maybe +0 if the PEP only allowed simple name targets, but
> decisively -1 for any assignment target in the current PEP.
But that's my point: you shouldn't need to wri
It's horrors like this:
g(items[idx] := idx := f())
That make me maybe +0 if the PEP only allowed simple name targets, but
decisively -1 for any assignment target in the current PEP.
I would much rather never have to read awful constructs like that than get
the minor convenience of:
if
On Sat, Apr 21, 2018 at 2:50 AM, Mike Miller wrote:
>
> On 2018-04-19 23:52, Chris Angelico wrote:
>>
>> And are limited to conditions that check the truthiness/falsiness of
>> the value you care about. So that works for re.match, but not for
>> anything that might return -1 (a lot of C APIs do th
On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth
wrote:
> Chris Barker - NOAA Federal wrote:
>
>> > Personally, I even slightly prefer
>> >
>> > a := 3
>> >
>> > to the commonplace
>> >
>> > a = 3
>> > because it visually expresses the asymmetry of the operation.
>>
>> Careful here! That’s a fine
On Sat, Apr 21, 2018 at 1:50 AM, Guido van Rossum wrote:
> Maybe annotations should get a brief mention in the Rejected Ideas section,
> with your explanation here added. (And maybe my response.)
Good idea. Actually, since it's a syntactic difference, I've promoted
it to the "Differences" section
Christoph's interpretation is correct. I don't rule that out. I also
separately proposed := as something that more people could get behind,
though perhaps it's all moot, and perhaps the PEP would gain clarity if it
went back to proposing "=". (Mostly kidding.)
On Fri, Apr 20, 2018 at 11:47 AM, Eth
On 04/20/2018 11:31 AM, Christoph Groth wrote:
Ethan Furman wrote:
On 04/20/2018 11:15 AM, Christoph Groth wrote:
OK, but then how about introducing assignment expressions with the "="
operator but *requiring* extra parens (similar to how modern C
compilers warn about assignment expressions w
Ethan Furman wrote:
> On 04/20/2018 11:15 AM, Christoph Groth wrote:
> > Nick Coghlan wrote:
> >
> >> I also think that if "=" and ":=" both target the same kind of scope,
> >> there isn't enough new expressiveness introduced by the latter to
> >> justify the syntactic complexity of adding it.
> >
On 04/20/2018 11:15 AM, Christoph Groth wrote:
Nick Coghlan wrote:
I also think that if "=" and ":=" both target the same kind of scope,
there isn't enough new expressiveness introduced by the latter to
justify the syntactic complexity of adding it.
OK, but then how about introducing assignme
Nick Coghlan wrote:
> I also think that if "=" and ":=" both target the same kind of scope,
> there isn't enough new expressiveness introduced by the latter to
> justify the syntactic complexity of adding it.
OK, but then how about introducing assignment expressions with the "="
operator but *req
On 2018-04-19 23:52, Chris Angelico wrote:
And are limited to conditions that check the truthiness/falsiness of
the value you care about. So that works for re.match, but not for
anything that might return -1 (a lot of C APIs do that, so if you're
working with a thin wrapper, that might be all yo
On Fri, 20 Apr 2018 13:25:02 +0200
Christoph Groth wrote:
>
> I think that this is the crucial point. If it is indeed a design
> principle of Python that expressions should not have the side-effect of
> assigning names, than the whole discussion of PEP 572 could have been
> stopped early on. I
Chris Barker - NOAA Federal wrote:
> > Personally, I even slightly prefer
> >
> > a := 3
> >
> > to the commonplace
> >
> > a = 3
> > because it visually expresses the asymmetry of the operation.
>
> Careful here! That’s a fine argument for using := in a new language,
> but people using := when th
ACTIVITY SUMMARY (2018-04-13 - 2018-04-20)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6587 (+15)
closed 38484 (+32)
total 45071 (+47)
Open issues wi
On 21 April 2018 at 01:49, Chris Angelico wrote:
> On Fri, Apr 20, 2018 at 10:51 PM, Paul Moore wrote:
>> 2. I hadn't really thought of the PEP in those terms. Now that you've
>> mentioned it, "Python has never before had syntax that assigns names
>> from within an expression" is quite a signific
On 20 April 2018 at 21:25, Christoph Groth wrote:
> Steven 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
Maybe annotations should get a brief mention in the Rejected Ideas section,
with your explanation here added. (And maybe my response.)
On Thu, Apr 19, 2018 at 11:31 PM, Chris Angelico wrote:
> On Fri, Apr 20, 2018 at 2:45 PM, Dmitry Malinovsky
> wrote:
> > Hello Chris, and thank you for working
On Fri, Apr 20, 2018 at 10:51 PM, Paul Moore wrote:
> 2. I hadn't really thought of the PEP in those terms. Now that you've
> mentioned it, "Python has never before had syntax that assigns names
> from within an expression" is quite a significant change, and one the
> PEP needs to examine the impl
On 04/20/2018 08:07 AM, Chris Barker - NOAA Federal wrote:
On 04/20/2018 04:25 AM, Christoph Groth wrote:
Personally, I even slightly prefer
a := 3
to the commonplace
a = 3
because it visually expresses the asymmetry of the operation.
Careful here! That’s a fine argument for using := in a
> Personally, I even slightly prefer
>
> a := 3
>
> to the commonplace
>
> a = 3
> because it visually expresses the asymmetry of the operation.
Careful here! That’s a fine argument for using := in a new language,
but people using := when they don’t need an expression because they
like the symbol
If you want type hints you can use a variable annotation without
initialization before the statement:
data: bytes
while data := stream.read():
print("Got", data)
On Thu, Apr 19, 2018 at 9:45 PM, Dmitry Malinovsky
wrote:
> Hello Chris, and thank you for working on this PEP!
>
> What do you t
On 20 April 2018 at 12:25, Christoph Groth wrote:
>> 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 now that we have
>> comprehensions and generator expressions)
Steven 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 initialization "problem" (not everyone
agrees these are even
On 2018-04-14 23:14, Guido van Rossum wrote:
That actually sounds like a pretty big problem. I'm sure there is lots
of code that doesn't *just* duck-type nor calls inspect but uses
isinstance() to decide how to extract the desired information.
I have been thinking about this some more...
One s
On Fri, Apr 20, 2018 at 6:32 PM, Paul Moore wrote:
>> def read_document(file):
>> doc = ""
>> while (token := file.get_next_token()) != "END":
>> doc += token
>> return doc
>>
>> The loop condition is "while the token is not END", or "while
>> get_next_token() doesn't return EN
On 20 April 2018 at 07:46, Chris Angelico wrote:
> 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
41 matches
Mail list logo
