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 leaking
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 scope in
> the case of a generator
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):
> > ... yield i
> > ...
> async def g():
> > ...
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 ge
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 functi
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 in
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 if you
> raise StopIteration
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 if you
> raise StopIteration in
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 gener
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 n
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
> > know how to fix your code?
>
> Right now, cal
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).
>
> Would it be possible to add
On 11/22/2017 01:40 PM, Ivan Levkivskyi wrote:
22 Лис 2017 22:33 "Ethan Furman" mailto:et...@stoneleaf.us>> пише:
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 didn't read my example car
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()]
> ...
g().send(None)
> Traceback
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 >
> >> wrote:
> >>>
> >>> On 22 November 2017 at 20:05, Guido va
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 th
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 a
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 shoul
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 type of the resulting f
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
comprehensio
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 expressions
> should
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
`expr
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 Pytho
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 wrote:
On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijls
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 <
>>> jelle.zijls...@gmail.com> wrote
>>>
2017-11-22 9:58 GM
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 :
>>>
>> (OTOH, await in the same position
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 not broken
>> and not unintuitive either.)
>>
>
>
This is very q
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 assigned a list, and the `yield`
>>> happens in the enclosing scope (s
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 function would have to be a
>> generator). This was
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 function would have to be
>> a generator). This was
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 believe.
>
> Another proposal
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 main disagreement seems to be about what thi
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
> >> wrote:
> >> > On 22 November 2017 at 17:24, Antoine Pitrou
> >> > 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 main disagreement seems to be about what this code should do:
g = [(yield i) for i in range(3)]
Currently, t
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
https://mail.python.org/mailman/lis
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 i
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
> >> wrote:
> >> > On 22 November 2017 at 17:24, Antoine Pitrou
> >> > wrote:
>
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 expression
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
>> > wrote:
>> >> Given a comprehension (e.g. list comprehension) is expected to
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 there's
> >> a difference between generator expressions and compre
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 (yield
foo())' actually d
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
>> thought both were intended to behave as if expa
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 work
> >> nominally as `constructor(generator expression)`
> >
>
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
Pytho
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 explained, these two are not equivalent if there i
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 >
> >> wrote:
> >> > On 22 November 2017 at 15:47, Paul Moore wrote:
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 Levkivskyi <
> levkivs...@gmail.com>
> > > wrote:
> > > > On 22 November
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 Moore wrote:
> > [...]
> > I'm all for prohibiting using 'yield' exp
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:
>
>r = (await f(i) for i in
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 wrote:
>> [...]
>> I'm all for prohibiting using 'yield' expression in gen
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:
> yield V
>r
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 generator
> expressions or comprehensions. The semantics is way to
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 summarize the current state:
> [...]
> > What d
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
>> tricky, I'd suggest we prohibit them both ;-)
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 in the docs it explains
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 defined in the language
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 code reviews exist. Also I am not sure how
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
>> > wrote:
>> >>
>> >> On Wed, 22 Nov 2017 15:03:09 +0200
>> >> Serhiy Storchak
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 tricky than `await` in a
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 wrote:
> >> > From
> >> >
> >> > https://stackoverflow.com/ques
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
>> https://stackoverflo
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
>> >
>> > https://stackoverflow.com/questions/45190729/differences-between-generator-comprehension-expressions
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 = [(yield i) for i in range(3)]
> >
> > Syntact
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
https://stackoverflow.com/questions/29334054/why-am-i-getting-different-results-when-usi
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 g should be a
> list
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
https://stackoverflow.com/questions/29334054/why-am-i-getting-different-results-when-using-a-list-comprehension-with-corou
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 fo
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 to
> > know how to fix your code?
>
> Right n
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
_PyRuntime_Initialize() cal
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 depending on the allocator
> set
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 time getting the allocators
>
74 matches
Mail list logo
