On Sat, Apr 21, 2018 at 12:30:36PM +1000, Chris Angelico wrote:
> There's that word "readability" again. Sometimes I wish the Zen of
> Python didn't use it, because everyone seems to think that "readable"
> means "code I like".
In fairness, if one can't read code, then one can hardly be expected
On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote:
> On Sat, Apr 21, 2018 at 12:30:36PM +1000, Chris Angelico wrote:
>> Introducing expression assignments will make these oddities even more
>> obvious. You'd be able to demonstrate things like this at function
>> scope, not just with a class.
On 21 April 2018 at 17:11, Steven D'Aprano wrote:
> So can you explain specifically what odd function-scope behaviour you
> are referring to? Give an example please?
Once we allow name binding as an expression, there are three main
cases to consider in comprehensions:
1. Name binding in the resu
On 20 April 2018 at 22:52, Brett Cannon wrote:
> 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 e
On 21/04/18 08:46, Chris Angelico wrote:
doubled_items = [x for x in (items := get_items()) if x * 2 in items]
This will leak 'items' into the surrounding scope (but not 'x').
At the risk of stating the obvious - wasn't there work in Python 3 to
prevent leakage from comprehensions ?
[x for x i
On Sat, Apr 21, 2018, 4:51 AM Paul Moore wrote:
> Just a usability note - the sign in procedure seems very weird. I
> tried to log in, but didn't want to create another independent account
> so I tried "Sign in with Google" and "Sign in with Github". Both took
> me round a loop of authorising the
On 21 April 2018 at 03:30, Chris Angelico wrote:
> There's that word "readability" again. Sometimes I wish the Zen of
> Python didn't use it, because everyone seems to think that "readable"
> means "code I like".
Readability is subjective, yes. But it's not the same as "liking". If
a significant
OK, got there now. Thanks for the help. That's a lousy sign-up
experience, though...
Paul
On 21 April 2018 at 09:55, Jonathan Goble wrote:
> On Sat, Apr 21, 2018, 4:51 AM Paul Moore wrote:
>>
>> Just a usability note - the sign in procedure seems very weird. I
>> tried to log in, but didn't want
On Sat, Apr 21, 2018 at 6:38 PM, Anthony Flury via Python-Dev
wrote:
> On 21/04/18 08:46, Chris Angelico wrote:
>>
>> doubled_items = [x for x in (items := get_items()) if x * 2 in items]
>>
>> This will leak 'items' into the surrounding scope (but not 'x').
>
> At the risk of stating the obvious
On Sat, Apr 21, 2018 at 7:12 PM, Paul Moore wrote:
> On 21 April 2018 at 03:30, Chris Angelico wrote:
>> There's that word "readability" again. Sometimes I wish the Zen of
>> Python didn't use it, because everyone seems to think that "readable"
>> means "code I like".
>
> Readability is subjectiv
On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote:
> On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote:
> > So can you explain specifically what odd function-scope behaviour you
> > are referring to? Give an example please?
>
> doubled_items = [x for x in (items := get_items())
Tim Peters wrote:
> [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 :-) Thi
On 21/04/18 11:18, Chris Angelico wrote:
But you haven't answered anything about what "readable" means. Does it
mean "if I look at this code, I can predict what dis.dis() would
output"? Or does it mean "this code clearly expresses an algorithm and
the programmer's intent"? Frequently I hear peopl
On Sat, Apr 21, 2018 at 10:26 PM, Steven D'Aprano wrote:
> On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote:
>> On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote:
>
>> > So can you explain specifically what odd function-scope behaviour you
>> > are referring to? Give an example
It feels very strange that the PEP tries to do two almost entirely
unrelated things. Assignment expressions are one thing, with merits and
demerits discussed at length.
But "fixing" comprehension scoping is pretty much completely orthogonal.
Sure, it might be a good idea. And yes there are interac
On 22 April 2018 at 01:44, David Mertz wrote:
> It feels very strange that the PEP tries to do two almost entirely unrelated
> things. Assignment expressions are one thing, with merits and demerits
> discussed at length.
>
> But "fixing" comprehension scoping is pretty much completely orthogonal.
It could also be postponed simply by saying assignment expressions follow
the same semantics as other bindings in comprehensions... which are subject
to change pending PEP (i.e. some different number).
On the other hand, I am one who doesn't really care about assignment
expressions in compreh
On Sat, Apr 21, 2018 at 03:44:48PM +, David Mertz wrote:
> It feels very strange that the PEP tries to do two almost entirely
> unrelated things. Assignment expressions are one thing, with merits and
> demerits discussed at length.
>
> But "fixing" comprehension scoping is pretty much complet
Chris Angelico writes:
> There's that word "readability" again. Sometimes I wish the Zen of
> Python didn't use it, because everyone seems to think that "readable"
> means "code I like".
Hey, man, that hurts. Some of us not only *have* precise statements
of the aspects of readability we invok
On Sun, Apr 22, 2018 at 12:45:36AM +1000, Chris Angelico wrote:
> > The reason I want items to "leak" into the surrounding scope is mostly
> > so that the initial value for it can be set with a simple assignment
> > outside the comprehension:
> >
> > items = (1, 2, 3)
> > [ ... items := it
On 2018-04-17 08:46, Chris Angelico wrote:
> Having survived four rounds in the boxing ring at python-ideas, PEP
> 572 is now ready to enter the arena of python-dev.
I would like to suggest one more motivating example for "Capturing
condition values": multiple regex matches with 'elif'.
if match
[Matthew Woodcraft ]
> I would like to suggest one more motivating example for "Capturing
> condition values": multiple regex matches with 'elif'.
>
> if match := re.search(pat1, text):
> print("Found one:", match.group(0))
> elif match := re.search(pat2, text):
> print("Found two:", match.
On 2018-04-21, 07:46 GMT, Chris Angelico wrote:
> doubled_items = [x for x in (items := get_items()) if x * 2 in
> items]
Aside from other concerns expressed elsewhere by other people,
do you really like this? I know and agree that “readability” is
a subjective term, but it is my firm persuasio
[Christoph Groth ]
> Tim, thanks for this clear analysis. Here's the best use case of more
> general assignment expressions that I can come up with (from real code
> I'm currently working on):
>
> class Basis:
> def __init__(self, parent, periods=()):
> self._parent = parent
>
[Tim]
>> 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" short of staring at
>> the genera
On 2018-04-21 19:02, Tim Peters wrote:
> [Matthew Woodcraft ]
>> I would like to suggest one more motivating example for "Capturing
>> condition values": multiple regex matches with 'elif'.
>>
>> if match := re.search(pat1, text):
>> print("Found one:", match.group(0))
>> elif match := re.searc
Tim Peters wrote:
> [Christoph Groth ]
> > Still, it seems weird to have two different ways of binding names in
> > the language where one would be sufficient (i.e. the old one would
> > remain only for backwards compatibility). From the point of view of
> > someone who's new to the language that'
The Zulip project maintainers are active on our instance so after you join
go to the Zulip stream and start a topic about this.
On Sat, Apr 21, 2018, 02:16 Paul Moore, wrote:
> OK, got there now. Thanks for the help. That's a lousy sign-up
> experience, though...
> Paul
>
> On 21 April 2018 at 0
On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote:
> Well, that's a reason to make the example a bit more realistic, then.
>
> Say:
>
> if match := re.search(pat1, text):
> do_something_with(match.group(0))
> elif match := re.search(pat2, text):
> do_something_else_with(m
Round 2 (Changed order, see below):
1. with open(fn) as f: # current behavior
2. with (open(fn) as f): # same
3. with closing(urlopen(url)) as dl: # current behavior
5. with (closing(urlopen(url)) as dl): # same
4. with closing(urlopen
On Sat, Apr 21, 2018 at 6:13 PM, Steven D'Aprano
wrote:
> On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote:
>
> > Well, that's a reason to make the example a bit more realistic, then.
> >
> > Say:
> >
> > if match := re.search(pat1, text):
> > do_something_with(match.group(0)
[Christoph Groth ]
>> > Still, it seems weird to have two different ways of binding names in
>> > the language where one would be sufficient (i.e. the old one would
>> > remain only for backwards compatibility). From the point of view of
>> > someone who's new to the language that's two things to
[Matthew Woodcraft]
>>> Well, that's a reason to make the example a bit more realistic, then.
>>>
>>> Say:
>>>
>>> if match := re.search(pat1, text):
>>> do_something_with(match.group(0))
>>> elif match := re.search(pat2, text):
>>> do_something_else_with(match.group(0), match.group(1))
>>>
On Sun, Apr 22, 2018 at 12:04 PM, Mike Miller wrote:
> Round 2 (Changed order, see below):
>
> 1. with open(fn) as f: # current behavior
> 2. with (open(fn) as f): # same
>
> 3. with closing(urlopen(url)) as dl: # current behavior
> 5. with (cl
On 22 April 2018 at 02:31, Steven D'Aprano wrote:
> This is not entirely unprecedented in Python: it is analogous
> (although not identical) to binding default values to parameters:
>
> def running_total(items, total=total):
> # Here total is local to the function, but the default
>
On 22 April 2018 at 03:41, Steven D'Aprano wrote:
> We *already* have the rule that the outermost iterable is special,
> except it isn't a rule precisely, since (as far as I know) it isn't
> documented anywhere, nor was it ever planned as a feature.
It's a deliberate feature of generator expressi
36 matches
Mail list logo