On 23 March 2018 at 06:34, Jeroen Demeyer wrote:
> Dear python-ideas,
>
> I would like to draft a PEP to change the implementation of functions and
> methods in CPython. The idea for this PEP come from a discussion on
> https://bugs.python.org/issue30071
>
> The core idea of the PEP is to reorgan
On 24 March 2018 at 13:15, Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 2:09 PM, Ethan Furman wrote:
> > I'm certainly hoping PEP 572 is rejected so we can have a follow-up PEP
> that
> > only deals with the assignment-as-expression portion.
> >
> > No offense intended, Chris! :) In fact, m
On 24 March 2018 at 04:09, Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 2:00 AM, Steven D'Aprano
> wrote:
> > I see you haven't mentioned anything about Nick Coglan's (long ago)
> > concept of a "where" block. If memory serves, it would be something
> > like:
> >
> > value = x**2 + 2*x wh
On 24 March 2018 at 14:41, Steven D'Aprano wrote:
> On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote:
> > >> Just as function-local names shadow global names for the scope of the
> > >> function, statement-local names shadow other names for that statement.
> > >> (They can technical
On Sat, Mar 24, 2018 at 8:07 PM, Christoph Groth
wrote:
> Chris Angelico wrote:
>
>> Thank you; both of these have now been incorporated into the document.
>
> Thanks! Just a small comment. You wrote in the PEP draft:
>
>> # Name bindings inside list comprehensions usually won't leak
>> ...
>> #
On Sat, Mar 24, 2018 at 3:16 PM, Masayuki YAMAMOTO
wrote:
> FWIW, I thought another way which provides cache object library, it seems to
> just work in some cases. But it doesn't create statement local scope and
> might be difficult to read because looks ordinary expression doing magic.
> Chris, w
Chris Angelico wrote:
> Thank you; both of these have now been incorporated into the document.
Thanks! Just a small comment. You wrote in the PEP draft:
> # Name bindings inside list comprehensions usually won't leak
> ...
> # But occasionally they will!
I don't understand what you mean here.
On Sat, Mar 24, 2018 at 3:41 PM, Steven D'Aprano wrote:
> To keep this a manageable length, I've trimmed vigourously. Apologies in
> advance if I've been too enthusiastic with the trimming :-)
>
> On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote:
>
>> No, I haven't yet. Sounds like a
On 24 March 2018 at 09:18, Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 8:07 PM, Christoph Groth
> wrote:
>> Chris Angelico wrote:
>>
>>> Thank you; both of these have now been incorporated into the document.
>>
>> Thanks! Just a small comment. You wrote in the PEP draft:
>>
>>> # Name bindi
On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore wrote:
> On 24 March 2018 at 09:18, Chris Angelico wrote:
>> Except that a list comprehension is implemented using an inner
>> function. Very approximately:
>>
>> x = [n * m for n in range(4) for m in range(5)]
>>
>> def (iter):
>> ret = []
>>
On 24 March 2018 at 09:49, Chris Angelico wrote:
>> Of course we don't want to necessarily impose unreasonable performance
>> and maintence costs on any implementation. But surely performance
>> cost is a quality of implementation issue. It ought to be a matter of
>> trade-offs: is the benefit suf
On 24 March 2018 at 11:55, Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore wrote:
>> On 24 March 2018 at 09:18, Chris Angelico wrote:
>>> Except that a list comprehension is implemented using an inner
>>> function. Very approximately:
>>>
>>> x = [n * m for n in range(4) for
On Sat, Mar 24, 2018 at 11:06 PM, Paul Moore wrote:
> On 24 March 2018 at 11:55, Chris Angelico wrote:
>> On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore wrote:
>>> On 24 March 2018 at 09:18, Chris Angelico wrote:
Except that a list comprehension is implemented using an inner
function. V
On 3/24/2018 5:49 AM, Chris Angelico wrote:
On Sat, Mar 24, 2018 at 3:41 PM, Steven D'Aprano wrote:
To keep this a manageable length, I've trimmed vigourously. Apologies in
advance if I've been too enthusiastic with the trimming :-)
On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico wrote
On 24 March 2018 at 12:18, Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 11:06 PM, Paul Moore wrote:
>> On 24 March 2018 at 11:55, Chris Angelico wrote:
>>> On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore wrote:
On 24 March 2018 at 09:18, Chris Angelico wrote:
> Except that a list comp
Chris Angelico wrote:
> On Sat, Mar 24, 2018 at 8:07 PM, Christoph Groth
> wrote:
> > Chris Angelico wrote:
> >
> >> Thank you; both of these have now been incorporated into the document.
> >
> > Thanks! Just a small comment. You wrote in the PEP draft:
> >
> >> # Name bindings inside list compr
On 24 March 2018 at 21:49, Paul Moore wrote:
> On 24 March 2018 at 09:18, Chris Angelico wrote:
> > So the first (outermost) iterable is actually evaluated in the
> > caller's scope, but everything else is inside a subscope. Thus an
> > assignment inside that first iterable WILL leak into the su
On 24 March 2018 at 23:29, Christoph Groth wrote:
>
> x = [n * m for n in range(4) for m in range(5)]
>
> be equally well equivalent to
>
> def ():
> ret = []
> for n in range(4):
> for m in range(5):
> ret.append(n * m)
> return ret
> x = ()
>
> As far as I can te
On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote:
> > I think that needs justification by more than just "it makes the
> > implementation easier".
>
> Introducing the new scoping behaviour doesn't make the implementation
> easier, it makes it harder.
[...]
Perhaps I had misunderstood
2018-03-24 17:14 GMT+03:00 Nick Coghlan :
>
>
> They can be distinguished, just not at module or function scope. To give a
> concrete example:
>
> ==
> >>> class C:
> ... sequence = range(10)
> ... listcomp = [x for x in sequence]
> ... def works(data):
> ...
On Sat, Mar 24, 2018 at 08:49:08PM +1100, Chris Angelico wrote:
> > [(spam, spam+1) for x in values for spam in (func(x),)]
> >
> > [(spam, spam+1) for spam in (func(x) for x in values)]
> >
> > They are the equivalent to "just add another assignment statement" for
> > comprehensions.
>
>
On 24/03/2018 14:44, Steven D'Aprano wrote:
On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote:
[...]
At a user experience level, the aim of the scoping limitation is
essentially to help improve "code snippet portability".
Consider the following piece of code:
squares = [x**2
On Sat, Mar 24, 2018 at 7:14 AM, Nick Coghlan wrote:
>
> >>> class C:
> ... sequence = range(10)
> ... listcomp = [x for x in sequence]
>
>>> class C:
... y = 1
... sequence = range(10)
... listcomp = [x+y for x in sequence]
...
Traceback (most recent call l
On 24/03/2018 16:02, Steven D'Aprano wrote:
Yes, I get functions, and I think function-scope is a sweet spot between
too few scopes and too many. Remember the bad old days of BASIC when all
variables were application-global? Even if you used GOSUB as a
second-rate kind of function, all the var
On 03/24/2018 07:44 AM, Steven D'Aprano wrote:
I don't think we need sub-function scoping. I think it adds more
complexity that outweighs whatever benefit it gives.
+1
--
~Ethan~
___
Python-ideas mailing list
[email protected]
https://mail.py
On 03/24/2018 09:27 AM, Rob Cliffe via Python-ideas wrote:
On 24/03/2018 14:44, Steven D'Aprano wrote:
On Sat, Mar 24, 2018 at 07:12:49PM +1000, Nick Coghlan wrote:
For PEP 572, the most directly comparable example is code like this:
# Any previous binding of "m" is lost completely on t
Dear Nick Coghlan,
First of all, thanks for your insightful comments!
On 2018-03-24 09:09, Nick Coghlan wrote:
As Antoine notes, unifying user-defined functions and builtin functions
would be fraught with backwards compatibility problems, so you probably
don't want to go down that path when you
On 25 March 2018 at 02:34, Eric Fahlgren wrote:
> On Sat, Mar 24, 2018 at 7:14 AM, Nick Coghlan wrote:
>
>>
>> >>> class C:
>> ... sequence = range(10)
>> ... listcomp = [x for x in sequence]
>>
>
> >>> class C:
> ... y = 1
> ... sequence = range(10)
> ... list
On 25 March 2018 at 01:03, Kirill Balunov wrote:
>
>
> 2018-03-24 17:14 GMT+03:00 Nick Coghlan :
>>
>>
>> They can be distinguished, just not at module or function scope. To give
>> a concrete example:
>>
>> ==
>> >>> class C:
>> ... sequence = range(10)
>> ... listcom
On 03/24/2018 01:35 AM, Nick Coghlan wrote:
In comprehensions and generator expressions, we'd need to explain why inline
assignments in the outermost iterator
expression leak but those in filter expressions, inner iterator expressions,
and result expressions don't.
I don't understand -- coul
On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman wrote:
> On 03/24/2018 01:35 AM, Nick Coghlan wrote:
>
>> In comprehensions and generator expressions, we'd need to explain why
>> inline assignments in the outermost iterator
>> expression leak but those in filter expressions, inner iterator
>> expres
On 25 March 2018 at 07:38, Jeroen Demeyer wrote:
> Dear Nick Coghlan,
>
> First of all, thanks for your insightful comments!
>
> On 2018-03-24 09:09, Nick Coghlan wrote:
>
>> As Antoine notes, unifying user-defined functions and builtin functions
>> would be fraught with backwards compatibility p
On 03/24/2018 08:51 PM, Chris Angelico wrote:
On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman wrote:
On 03/24/2018 01:35 AM, Nick Coghlan wrote:
In comprehensions and generator expressions, we'd need to explain why
inline assignments in the outermost iterator
expression leak but those in filter
On Sun, Mar 25, 2018 at 2:59 PM, Ethan Furman wrote:
> On 03/24/2018 08:51 PM, Chris Angelico wrote:
>>
>> On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman wrote:
>>>
>>> On 03/24/2018 01:35 AM, Nick Coghlan wrote:
>>>
In comprehensions and generator expressions, we'd need to explain why
in
On 03/24/2018 09:00 PM, Chris Angelico wrote:
On Sun, Mar 25, 2018 at 2:59 PM, Ethan Furman wrote:
On 03/24/2018 08:51 PM, Chris Angelico wrote:
Let's suppose we have assignment expressions. I'm going to use "(expr
as name)" syntax for this example.
a = [(1 as b) for c in (d as e) if (2 as f
On 25 March 2018 at 13:51, Chris Angelico wrote:
> On Sun, Mar 25, 2018 at 2:48 PM, Ethan Furman wrote:
> > On 03/24/2018 01:35 AM, Nick Coghlan wrote:
> >
> >> In comprehensions and generator expressions, we'd need to explain why
> >> inline assignments in the outermost iterator
> >> expression
On Sun, Mar 25, 2018 at 3:08 PM, Ethan Furman wrote:
> On 03/24/2018 09:00 PM, Chris Angelico wrote:
>>
>> On Sun, Mar 25, 2018 at 2:59 PM, Ethan Furman wrote:
>>>
>>> On 03/24/2018 08:51 PM, Chris Angelico wrote:
>
>
Let's suppose we have assignment expressions. I'm going to use "(expr
On 25 March 2018 at 14:08, Ethan Furman wrote:
> Looks like a buggy implementation detail. Any assignments that happen
> inside a listcomp should be effective only inside the listcomp.
>
No, the fact that the expression defining the outermost iterable gets
evaluated in the outer scope is behavi
On Sat, Mar 24, 2018 at 7:08 PM, Nick Coghlan wrote:
> On 25 March 2018 at 02:34, Eric Fahlgren wrote:
>
>> On Sat, Mar 24, 2018 at 7:14 AM, Nick Coghlan wrote:
>>
>>>
>>> >>> class C:
>>> ... sequence = range(10)
>>> ... listcomp = [x for x in sequence]
>>>
>>
>> >>> cla
This is a super complex topic. There are at least three separate levels of
critique possible, and all are important.
First there is the clarity of the PEP. Steven D'Aprano has given you great
detailed feedback here and you should take it to heart (even if you
disagree with his opinion about the sp
40 matches
Mail list logo
