On 23.11.2017 08:38, Ivan Levkivskyi wrote:
I think this code should be just equivalent to this code
def g():
temp = [(yield i) for i in range(10)]
return (v for v in temp)
Semantics of the comprehension should be clear here (just an
equivalent for-loop without name
On 23 November 2017 at 05:44, Greg Ewing
wrote:
> Ivan Levkivskyi wrote:
>
>> The key idea is that neither comprehensions nor generator expressions
>> should create a function scope surrounding the `expr`
>>
>
> I don't see how you can avoid an implicit function
On 23 November 2017 at 01:00, Yury Selivanov
wrote:
> On Wed, Nov 22, 2017 at 6:46 PM, Ivan Levkivskyi
> wrote:
> [..]
> > Just found another example of intuitive behaviour:
> >
> async def f():
> > ... for i in range(3):
> > ...
On 11/22/2017 07:00 PM, Yury Selivanov wrote:
> I wouldn't say that it's obvious to anyone...
>
> I think this thread has started to discuss the use of 'yield'
> expression in comprehensions, and the outcome of the discussion is
> that everyone thinks that we should deprecate that syntax in 3.7,
Greg Ewing writes:
> Consider this:
>
> def g():
>return ((yield i) for i in range(10))
>
> Presumably the yield should turn g into a generator, but...
> then what? My brain is hurting trying to figure out what
> it should do.
I don't understand why you presume that. The
On 23 November 2017 at 15:33, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> However, my model of comprehensions is exactly a for loop that appends
> to an empty list repeatedly, but doesn't leak iteration variables.
Not since Python 3.0. Instead, they create a nested
Paul Moore writes:
> 1. List comprehensions expand into nested for/if statements in the
> "obvious" way - with an empty list created to start and append used to
> add items to it.
>1a. Variables introduced in the comprehension don't "leak" (see below).
> 2. Generator expressions expand
On Thu, Nov 23, 2017 at 3:36 PM, Greg Ewing wrote:
> Paul Moore wrote:
>>
>> 3. List comprehensions are the same as list(the equivalent generator
>> expression).
>
>
> I don't think that's ever been quite true -- there have
> always been odd cases such as what happens
On 23 November 2017 at 14:36, Greg Ewing
wrote:
> Paul Moore wrote:
>
>> 3. List comprehensions are the same as list(the equivalent generator
>> expression).
>>
>
> I don't think that's ever been quite true -- there have
> always been odd cases such as what happens
Ivan Levkivskyi wrote:
The key idea is that neither comprehensions nor generator expressions
should create a function scope surrounding the `expr`
I don't see how you can avoid an implicit function scope in
the case of a generator expression, though. And I can't see
how to make yield in a
Paul Moore wrote:
3. List comprehensions are the same as list(the equivalent generator
expression).
I don't think that's ever been quite true -- there have
always been odd cases such as what happens if you
raise StopIteration in list(generator_expression).
To my mind, these equivalences have
On 22 November 2017 at 21:12, Victor Stinner
wrote:
> 2017-11-22 12:04 GMT+01:00 Antoine Pitrou :
> > IMHO this really needs a simple solution documented somewhere. Also,
> > hopefully when you do the wrong thing, you get a clear error message to
>
Aha, contextlib.nullcontext() was just added, cool!
https://github.com/python/cpython/commit/0784a2e5b174d2dbf7b144d480559e650c5cf64c
https://bugs.python.org/issue10049
Victor
2017-09-09 21:54 GMT+02:00 Victor Stinner :
> I always wanted this feature (no kidding).
>
>
On 11/22/2017 01:40 PM, Ivan Levkivskyi wrote:
22 Лис 2017 22:33 "Ethan Furman" > пише:
Right, the argument is that calling the `list` constructor should return a list
-- not a database proxy, not a web
page, and not a generator.
Then you
On Wed, Nov 22, 2017 at 6:46 PM, Ivan Levkivskyi wrote:
[..]
> Just found another example of intuitive behaviour:
>
async def f():
> ... for i in range(3):
> ... yield i
> ...
async def g():
> ... return [(yield i) async for i in f()]
> ...
On 22 November 2017 at 21:07, Yury Selivanov
wrote:
> On Wed, Nov 22, 2017 at 2:37 PM, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 20:33, Guido van Rossum wrote:
> >>
> >> On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
Paul Moore wrote:
At the moment, I know I tend to treat Python semantics as I always
did, but with an implicit proviso, "unless async is involved, when I
can't assume any of my intuitions apply". That's *not* a good
situation to be in.
It's disappointing that PEP 3152 was rejected, because I
Hi,
I hope that what follows will be useful for other people: after stepping
through code for a few hours this morning, I ended up finding the location
of the boostrapping executable. It (they) actually ship with setuptools,
e.g. C:\Python27\Lib\site-packages\setuptools\cli-64.exe and get copied
Ivan Levkivskyi wrote:
while `g = list((yield i) for i in range(3))` is defined as this code:
def __gen():
for i in range(3):
yield (yield i)
g = list(__gen())
Since this is almost certainly not what was intended, I think that
'yield' inside a generator expression
22 Лис 2017 22:33 "Ethan Furman" пише:
On 11/22/2017 01:25 PM, Ivan Levkivskyi wrote:
> 22 Лис 2017 22:19 "Ethan Furman" пише:
>
Whether it's inside or outside a function should be irrelevant -- a
>> comprehension / generator expression should have
>> no influence on the
On 11/22/2017 01:25 PM, Ivan Levkivskyi wrote:
22 Лис 2017 22:19 "Ethan Furman" пише:
Whether it's inside or outside a function should be irrelevant -- a
comprehension / generator expression should have
no influence on the type of the resulting function (and at least synchronous
22 Лис 2017 22:19 "Ethan Furman" пише:
On 11/22/2017 11:01 AM, Ivan Levkivskyi wrote:
I think how to formulate these rules more "precisely" so that they will be
> all consistent even if there is a
> `yield` inside.
> The key idea is that neither comprehensions nor generator
On 11/22/2017 11:01 AM, Ivan Levkivskyi wrote:
I think how to formulate these rules more "precisely" so that they will be all
consistent even if there is a
`yield` inside.
The key idea is that neither comprehensions nor generator expressions should
create a function scope surrounding the
Isn't yield like a return?
A return in a list/dict/set comprehension makes no sense to me.
So, +1 on SyntaxError from me too.
Cheers.
On 22.11.2017 21:29, David Mertz wrote:
Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no
behavior for that spelling that I would find intuitive
Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior for
that spelling that I would find intuitive or easy to explain to students.
And as far as I can tell, the ONLY time anything has ever been spelled that
way is in comments saying "look at this weird edge case behavior in
On Wed, Nov 22, 2017 at 2:37 PM, Ivan Levkivskyi wrote:
> On 22 November 2017 at 20:33, Guido van Rossum wrote:
>>
>> On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
>> wrote:
>>>
>>> On 22 November 2017 at 20:05, Guido van Rossum
On 22 November 2017 at 20:33, Guido van Rossum wrote:
> On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
> wrote:
>
>> On 22 November 2017 at 20:05, Guido van Rossum wrote:
>>
>>> On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra <
>>>
On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
wrote:
> On 22 November 2017 at 20:05, Guido van Rossum wrote:
>
>> On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra <
>> jelle.zijls...@gmail.com> wrote
>>
>>> 2017-11-22 9:58 GMT-08:00 Guido van Rossum
On 22 November 2017 at 20:05, Guido van Rossum wrote:
> On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra > wrote
>
>> 2017-11-22 9:58 GMT-08:00 Guido van Rossum :
>>
> (OTOH, await in the same position must keep working since it's
On 22 November 2017 at 20:15, Guido van Rossum wrote:
> On Wed, Nov 22, 2017 at 11:08 AM, Ivan Levkivskyi
> wrote:
>
>> On 22 November 2017 at 19:54, Jelle Zijlstra
>> wrote:
>>
>>>
>>> One proposal is to make it so `g` gets
On Wed, Nov 22, 2017 at 2:08 PM, Ivan Levkivskyi wrote:
> On 22 November 2017 at 19:54, Jelle Zijlstra
> wrote:
>>
>>
>> One proposal is to make it so `g` gets assigned a list, and the `yield`
>> happens in the enclosing scope (so the enclosing
On Wed, Nov 22, 2017 at 11:08 AM, Ivan Levkivskyi
wrote:
> On 22 November 2017 at 19:54, Jelle Zijlstra
> wrote:
>
>>
>> One proposal is to make it so `g` gets assigned a list, and the `yield`
>> happens in the enclosing scope (so the enclosing
On 22 November 2017 at 19:54, Jelle Zijlstra
wrote:
>
> One proposal is to make it so `g` gets assigned a list, and the `yield`
> happens in the enclosing scope (so the enclosing function would have to be
> a generator). This was the way things worked in Python 2, I
On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra
wrote:
>
>
> 2017-11-22 9:58 GMT-08:00 Guido van Rossum :
>
>> Wow, 44 messages in 4 hours. That must be some kind of record.
>>
>> If/when there's an action item, can someone summarize for me?
>>
>> The
On 22 November 2017 at 18:15, Paul Moore wrote:
> On 22 November 2017 at 16:47, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:43, Paul Moore wrote:
> >>
> >> On 22 November 2017 at 16:30, Ivan Levkivskyi
2017-11-22 9:58 GMT-08:00 Guido van Rossum :
> Wow, 44 messages in 4 hours. That must be some kind of record.
>
> If/when there's an action item, can someone summarize for me?
>
> The main disagreement seems to be about what this code should do:
g = [(yield i) for i in
22.11.17 17:10, Ivan Levkivskyi пише:
- fix yield in comprehensions
I'm working on this. I was going to inline the generating function a
long time ago for small performance benefit, but the benefit looked too
small for complicating the compiler code. Now I have other reason for
doing this.
Wow, 44 messages in 4 hours. That must be some kind of record.
If/when there's an action item, can someone summarize for me?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
On 11/22/2017 05:03 AM, Serhiy Storchaka wrote:
From
https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions.
g = [(yield i) for i in range(3)]
Syntactically this looks like a list comprehension, and g should be a list,
right? But actually
On 22 November 2017 at 18:15, Paul Moore wrote:
> On 22 November 2017 at 16:47, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:43, Paul Moore wrote:
> >>
> >> On 22 November 2017 at 16:30, Ivan Levkivskyi
On 11/22/2017 09:15 AM, Paul Moore wrote:
1. List comprehensions expand into nested for/if statements in the
"obvious" way - with an empty list created to start and append used to
add items to it.
1a. Variables introduced in the comprehension don't "leak" (see below).
2. Generator
On 22 November 2017 at 16:47, Ivan Levkivskyi wrote:
> On 22 November 2017 at 17:43, Paul Moore wrote:
>>
>> On 22 November 2017 at 16:30, Ivan Levkivskyi
>> wrote:
>> > On 22 November 2017 at 17:24, Antoine Pitrou
On 22 November 2017 at 17:50, Paul Moore wrote:
> On 22 November 2017 at 16:38, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:16, Paul Moore wrote:
> >>
> >> Docs more importantly than PEP IMO. And are you implying that
On Wed, Nov 22, 2017 at 11:11 AM, Paul Moore wrote:
[..]
> But by the logic you just described, await isn't (or shouldn't be)
> allowed, surely?
No, that's a stretch. People can understand and actually use 'yield
(await foo())', but they usually can't figure what 'yield
On 22 November 2017 at 16:38, Ivan Levkivskyi wrote:
> On 22 November 2017 at 17:16, Paul Moore wrote:
>>
>> Docs more importantly than PEP IMO. And are you implying that there's
>> a difference between generator expressions and comprehensions? I
>>
On 22 November 2017 at 17:43, Paul Moore wrote:
> On 22 November 2017 at 16:30, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 17:24, Antoine Pitrou
> wrote:
> >> Given a comprehension (e.g. list comprehension) is expected to
Sorry, forgot some details in the second "definition":
try:
def __gen():
for i in range(3):
yield (yield i)
g = list(__gen())
finally:
del __gen
--
Ivan
___
Python-Dev mailing list
On 22 November 2017 at 16:30, Ivan Levkivskyi wrote:
> On 22 November 2017 at 17:24, Antoine Pitrou wrote:
>> Given a comprehension (e.g. list comprehension) is expected to work
>> nominally as `constructor(generator expression)`
>
> As Yury just
On 22 November 2017 at 17:16, Paul Moore wrote:
> On 22 November 2017 at 16:08, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 16:56, Yury Selivanov
> > wrote:
> >>
> >> On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
On 22 November 2017 at 17:24, Antoine Pitrou wrote:
> On Wed, 22 Nov 2017 17:08:14 +0100
> Ivan Levkivskyi wrote:
> > On 22 November 2017 at 16:56, Yury Selivanov
> > wrote:
> >
> > > On Wed, Nov 22, 2017 at 10:10 AM, Ivan
On Wed, 22 Nov 2017 17:08:14 +0100
Ivan Levkivskyi wrote:
> On 22 November 2017 at 16:56, Yury Selivanov
> wrote:
>
> > On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
> > wrote:
> > > On 22 November 2017 at 15:47, Paul
On 22 November 2017 at 15:56, Yury Selivanov wrote:
> For synchronous generator expression:
>
>r = (f(i) for i in range(3))
>
> is really:
>
>def _():
> for i in range(3):
> yield f(i)
>r = _()
>
> For an asynchronous generator expression:
>
>
On 22 November 2017 at 16:08, Ivan Levkivskyi wrote:
> On 22 November 2017 at 16:56, Yury Selivanov
> wrote:
>>
>> On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
>> wrote:
>> > On 22 November 2017 at 15:47, Paul Moore
On 22 November 2017 at 15:56, Yury Selivanov wrote:
> "await" in generator expressions works *correct*. I explained it here:
> https://bugs.python.org/issue32113
>
> To clarify a bit more:
>
>r = (V for I in X)
>
> is equivalent to:
>
>def _():
> for I in X:
On 22 November 2017 at 16:56, Yury Selivanov
wrote:
> On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 15:47, Paul Moore wrote:
> [...]
> I'm all for prohibiting using 'yield' expression in
On 22 November 2017 at 16:53, Paul Moore wrote:
> On 22 November 2017 at 15:10, Ivan Levkivskyi
> wrote:
> > I think there may be a small misunderstanding here. The situation is
> > different for comprehensions and generator expressions,
> > let me
On Wed, Nov 22, 2017 at 10:10 AM, Ivan Levkivskyi wrote:
> On 22 November 2017 at 15:47, Paul Moore wrote:
>>
>> I generally don't understand "await" in any context, so I deferred
>> judgement on that :-) Based on your comment that they are equally
>>
On 22 November 2017 at 15:10, Ivan Levkivskyi wrote:
> I think there may be a small misunderstanding here. The situation is
> different for comprehensions and generator expressions,
> let me summarize the current state:
[...]
> What do you think?
Can you point me to where
On 22 November 2017 at 15:47, Paul Moore wrote:
> I generally don't understand "await" in any context, so I deferred
> judgement on that :-) Based on your comment that they are equally
> tricky, I'd suggest we prohibit them both ;-)
>
> Less facetiously, comprehensions are
On 22 November 2017 at 15:46, Antoine Pitrou wrote:
> On Wed, 22 Nov 2017 15:15:49 +0100
> Ivan Levkivskyi wrote:
> > There are many things that I would reject in code review, but they are
> > still allowed in Python,
> > this is one of the reasons why
On 22 November 2017 at 14:15, Ivan Levkivskyi wrote:
> On 22 November 2017 at 15:09, Paul Moore wrote:
>>
>> On 22 November 2017 at 13:53, Ivan Levkivskyi
>> wrote:
>> > On 22 November 2017 at 14:38, Antoine Pitrou
On Wed, 22 Nov 2017 15:15:49 +0100
Ivan Levkivskyi wrote:
> There are many things that I would reject in code review, but they are
> still allowed in Python,
> this is one of the reasons why code reviews exist. Also I am not sure how
> `yield` in a comprehension
> is more
On 22 November 2017 at 15:09, Paul Moore wrote:
> On 22 November 2017 at 13:53, Ivan Levkivskyi
> wrote:
> > On 22 November 2017 at 14:38, Antoine Pitrou
> wrote:
> >>
> >> On Wed, 22 Nov 2017 15:03:09 +0200
> >> Serhiy Storchaka
On 22 November 2017 at 14:53, Serhiy Storchaka wrote:
> 22.11.17 15:25, Ivan Levkivskyi пише:
>
>> I think this is indeed a problem.. For me the biggest surprise was that
>> `yield` inside a comprehension does not turn a surrounding function into
>> comprehension, see also
On 22 November 2017 at 13:53, Ivan Levkivskyi wrote:
> On 22 November 2017 at 14:38, Antoine Pitrou wrote:
>>
>> On Wed, 22 Nov 2017 15:03:09 +0200
>> Serhiy Storchaka wrote:
>> > From
>> >
>> >
On 22 November 2017 at 14:38, Antoine Pitrou wrote:
> On Wed, 22 Nov 2017 15:03:09 +0200
> Serhiy Storchaka wrote:
> > From
> > https://stackoverflow.com/questions/45190729/
> differences-between-generator-comprehension-expressions.
> >
> > g =
22.11.17 15:25, Ivan Levkivskyi пише:
I think this is indeed a problem.. For me the biggest surprise was that
`yield` inside a comprehension does not turn a surrounding function into
comprehension, see also
On Wed, 22 Nov 2017 15:03:09 +0200
Serhiy Storchaka wrote:
> From
> https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions.
>
> g = [(yield i) for i in range(3)]
>
> Syntactically this looks like a list comprehension, and
Serhiy,
I think this is indeed a problem. For me the biggest surprise was that
`yield` inside a comprehension does not turn a surrounding function into
comprehension, see also
From
https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions.
g = [(yield i) for i in range(3)]
Syntactically this looks like a list comprehension, and g should be a
list, right? But actually it is a generator. This code is equivalent to
the
On Wed, 22 Nov 2017 12:12:32 +0100
Victor Stinner wrote:
> 2017-11-22 12:04 GMT+01:00 Antoine Pitrou :
> > IMHO this really needs a simple solution documented somewhere. Also,
> > hopefully when you do the wrong thing, you get a clear error message
2017-11-22 12:04 GMT+01:00 Antoine Pitrou :
> IMHO this really needs a simple solution documented somewhere. Also,
> hopefully when you do the wrong thing, you get a clear error message to
> know how to fix your code?
Right now, calling PyMem_RawMalloc() before calling
On Wed, 22 Nov 2017 10:38:32 +0100
Victor Stinner wrote:
>
> I fixed the issue by calling _PyRuntime_Initialize() as the very first
> function in main().
>
> I also had to add _PyMem_GetDefaultRawAllocator() to get a
> deterministic memory allocator, rather than
2017-11-21 16:57 GMT+01:00 Eric Snow :
>> I understand that moving global variables to _PyRuntime helps to
>> clarify how these variables are initialized and then finalized, but
>> memory allocators are a complex corner case.
>
> Agreed. I spent a large portion of my
74 matches
Mail list logo