Thanks for being a good sport, Raymond! I've probably spent too much time
fretting about this, so thanks for the reminder. I want to get back to
other things too, in particular the type hinting PEP: there's a draft, but
there are many things we --the co-authors-- want to change before we bother
the
> On Nov 27, 2014, at 8:52 AM, Guido van Rossum wrote:
>
> I understand that @allow_import_stop represents a compromise, an attempt at
> calming the waves that PEP 479 has caused. But I still want to push back
> pretty hard on this idea.
>
> - It means we're forever stuck with two possible se
On 28 November 2014 at 02:52, Guido van Rossum wrote:
> On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan wrote:
>> If compatibility with older Python versions is needed, then you could
>> put something like the following in a compatibility module:
>>
>> try:
>> from itertools import allo
On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan wrote:
> On 27 November 2014 at 11:15, Guido van Rossum wrote:
> > On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan
> wrote:
> >>
> >> On 27 Nov 2014 06:35, "Guido van Rossum" wrote:
> >>
> >> [...]
> >>
> >> > I think we can put a number to "much fas
On 27 November 2014 at 11:15, Guido van Rossum wrote:
> On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan wrote:
>>
>> On 27 Nov 2014 06:35, "Guido van Rossum" wrote:
>>
>> [...]
>>
>> > I think we can put a number to "much faster" now -- 150 nsec per
>> > try/except.
>> >
>> > I have serious misgiv
On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan wrote:
> On 27 Nov 2014 06:35, "Guido van Rossum" wrote:
> [...]
>
> > I think we can put a number to "much faster" now -- 150 nsec per
> try/except.
> >
> > I have serious misgivings about that decorator though -- I'm not sure
> how viable it is to
On Thu, Nov 27, 2014 at 12:11 PM, Guido van Rossum wrote:
> A decorator with a side effect *elsewhere* (like the route registrations) is
> acceptable; one with a side effect *on the decorated function* is
> questionable, and instead the decorator should behave "functionally", i.e.
> return a new o
A decorator with a side effect *elsewhere* (like the route registrations)
is acceptable; one with a side effect *on the decorated function* is
questionable, and instead the decorator should behave "functionally", i.e.
return a new object instead.
On Wed, Nov 26, 2014 at 5:07 PM, Chris Angelico wr
On Thu, Nov 27, 2014 at 12:01 PM, Guido van Rossum wrote:
> Well, that's just a general problem with decorator ordering.
Indeed. I was hoping it could be avoided in this instance by just
altering __code__ on an existing function, but if that's not possible,
we fall back to what is, after all, a k
Well, that's just a general problem with decorator ordering.
On Wed, Nov 26, 2014 at 4:57 PM, Chris Angelico wrote:
> On Thu, Nov 27, 2014 at 11:50 AM, Guido van Rossum
> wrote:
> > No, that was a figure of speech. The proposed decorator returns a new
> > function object that references a new c
On Thu, Nov 27, 2014 at 11:50 AM, Guido van Rossum wrote:
> No, that was a figure of speech. The proposed decorator returns a new
> function object that references a new code object. The original function and
> code object are unchanged.
Then it has a potentially-confusing interaction with decora
No, that was a figure of speech. The proposed decorator returns a new
function object that references a new code object. The original function
and code object are unchanged.
On Wed, Nov 26, 2014 at 4:38 PM, Chris Angelico wrote:
> On Thu, Nov 27, 2014 at 11:33 AM, Guido van Rossum
> wrote:
> >
On Thu, Nov 27, 2014 at 11:33 AM, Guido van Rossum wrote:
> The design just copies the code object with one flag set differently. Code
> objects are immutable but they can be copied (though the interface to do
> that is kind of hidden).
Yes, but the proposal as written spoke of replacing the gene
The design just copies the code object with one flag set differently. Code
objects are immutable but they can be copied (though the interface to do
that is kind of hidden).
On Wed, Nov 26, 2014 at 4:03 PM, Chris Angelico wrote:
> On Thu, Nov 27, 2014 at 9:53 AM, Nick Coghlan wrote:
> > The impl
On Thu, Nov 27, 2014 at 9:53 AM, Nick Coghlan wrote:
> The implicit stop decorator would then check the flags on the code object
> attached to the passed in function. If GENERATOR wasn't set, that would be
> an immediate ValueError, while if EXPLICIT_STOP wasn't set, the generator
> function would
On 27 Nov 2014 06:35, "Guido van Rossum" wrote:
>
> On Wed, Nov 26, 2014 at 3:24 AM, Nick Coghlan wrote:
>> After thinking about that concern for a while, I'd like to suggest the
>> idea of having a new builtin "allow_implicit_stop" decorator that
>> swaps out a GENERATOR code object that has the
On Wed, Nov 26, 2014 at 3:24 AM, Nick Coghlan wrote:
> On 26 November 2014 at 18:30, Greg Ewing
> wrote:
> > Guido van Rossum wrote:
> >>
> >> Hm, that sounds like you're either being contrarian or Chris and I have
> >> explained it even worse than I thought.
> >
> > I'm not trying to be contrar
On 11/26/2014 03:24 AM, Nick Coghlan wrote:
>
> After thinking about that concern for a while, I'd like to suggest the
> idea of having a new builtin "allow_implicit_stop" decorator that
> swaps out a GENERATOR code object that has the new "EXPLICIT_STOP"
> flag set for one with it cleared (attemp
On Thu, Nov 27, 2014 at 2:55 AM, Hrvoje Niksic wrote:
> To retrieve a single value from an iterator, one can use the for/break/else
> idiom:
>
> def my_generator():
> ...
> for val in it:
> yield val
> break
> else:
> return
> ...
While that does work, it's
On 11/26/2014 12:24 PM, Nick Coghlan wrote:
Now needs to be written out explicitly as:
def my_generator():
...
try:
yield next(it)
except StopIteration
return
...
To retrieve a single value from an iterator, one can use the
for
On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan wrote:
> On 26 November 2014 at 18:30, Greg Ewing wrote:
>> Guido van Rossum wrote:
>>>
>>> Hm, that sounds like you're either being contrarian or Chris and I have
>>> explained it even worse than I thought.
>>
>> I'm not trying to be contrary, I jus
On Wed, Nov 26, 2014 at 10:24 PM, Nick Coghlan wrote:
> The other key aspect is that it changes the answer to the question
> "How do I gracefully terminate a generator function?". The existing
> behaviour has an "or" in the answer: "return from the generator frame,
> OR raise StopIteration from th
On 26 November 2014 at 21:44, Petr Viktorin wrote:
> On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan wrote:
>> Now needs to be written out explicitly as:
>>
>> def my_generator():
>> ...
>>try:
>> yield next(it)
>> except StopIteration
>> return
On 26 November 2014 at 18:30, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> Hm, that sounds like you're either being contrarian or Chris and I have
>> explained it even worse than I thought.
>
> I'm not trying to be contrary, I just think the PEP could
> explain more clearly what you're trying
Guido van Rossum wrote:
Hm, that sounds like you're either being contrarian or Chris and I have
explained it even worse than I thought.
I'm not trying to be contrary, I just think the PEP could
explain more clearly what you're trying to achieve. The
rationale is too vague and waffly at the mome
On Wed, Nov 26, 2014 at 11:58 AM, Greg wrote:
> The Abstract claims that the proposal will "unify the behaviour of
> list comprehensions and generator expressions", but it doesn't do
> that.
I don't know that it completely unifies the behaviours, but it does
merge them on the specific situation o
On Tue, Nov 25, 2014 at 4:58 PM, Greg wrote:
> I'm not particularly opposed to PEP 479, but the Abstract and
> Rationale could do with considerable clarification.
I know.
> They currently
> appear to promise things that are in disagreement with what the PEP
> actually delivers.
>
> The Abstra
I'm not particularly opposed to PEP 479, but the Abstract and
Rationale could do with considerable clarification. They currently
appear to promise things that are in disagreement with what the PEP
actually delivers.
The Abstract claims that the proposal will "unify the behaviour of
list comprehen
On 25 November 2014 at 10:47, Guido van Rossum wrote:
> In my defense, the docs for the warnings module on docs.python.org at start
> like this:
>
> "Warning messages are typically issued in situations where it is useful to
> alert the user of some condition in a program, where that condition
> (n
On Mon, Nov 24, 2014 at 3:07 PM, Isaac Schwabacher
wrote:
> On 11/24/14, Guido van Rossum wrote:
> > On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher <
> ischwabac...@wisc.edu
> ischwabac...@wisc.edu> wrote:
> >
> > > On 11/24/14, Guido van Rossum wrote:
> > > > On Mon, Nov 24, 2014 at 8:14 A
On 11/24/14, Guido van Rossum wrote:
> On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher ischwabac...@wisc.edu> wrote:
>
> > On 11/24/14, Guido van Rossum wrote:
> > > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher
> > > > > 't=ischwabac...@wisc.edu>(java_script:main.compose()> wrote:
> >
On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher
wrote:
> On 11/24/14, Guido van Rossum wrote:
> > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <
> ischwabac...@wisc.edu(javascript:main.compose()> wrote:
> >
> > > On 11/23/14, Guido van Rossum wrote:
> > >
> > > > It wouldn't be so bad i
On 11/24/14, Guido van Rossum wrote:
> On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher
> wrote:
>
> > On 11/23/14, Guido van Rossum wrote:
> >
> > > It wouldn't be so bad if we had the occasional generator author writing
> > > "raise StopIteration" instead of "return" to exit from a genera
On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher
wrote:
> On 11/23/14, Guido van Rossum wrote:
>
> > It wouldn't be so bad if we had the occasional generator author writing
> "raise StopIteration" instead of "return" to exit from a generator. (We
> could just add a recommendation against this
On 11/23/14, Guido van Rossum wrote:
> It wouldn't be so bad if we had the occasional generator author writing
> "raise StopIteration" instead of "return" to exit from a generator. (We could
> just add a recommendation against this to the style guide.) But the problem
> is that an unguarded ne
On 11/23/14, Mark Shannon wrote:
>
[...]
>
> You are grouping next() and it.__next__() together, but they are different.
> I think we agree that the __next__() method is part of the iterator
> protocol and should raise StopIteration.
> There is no fundamental reason why next(), the builtin functio
Chris already responded; I'll top-post to clarify my position.
I acted quickly because too many people were expending too much energy
debating the issue without coming up with a different resolution, and I am
unhappy with the status quo.
Many people don't seem to see the difference between the it
On 23/11/14 22:54, Chris Angelico wrote:
On Mon, Nov 24, 2014 at 7:18 AM, Mark Shannon wrote:
Hi,
I have serious concerns about this PEP, and would ask you to reconsider it.
Hoping I'm not out of line in responding here, as PEP author. Some of
your concerns (eg "5 days is too short") are c
On Mon, Nov 24, 2014 at 7:18 AM, Mark Shannon wrote:
> Hi,
>
> I have serious concerns about this PEP, and would ask you to reconsider it.
Hoping I'm not out of line in responding here, as PEP author. Some of
your concerns (eg "5 days is too short") are clearly for Guido, not
me, but perhaps I ca
Hi,
I have serious concerns about this PEP, and would ask you to reconsider it.
[ Very short summary:
Generators are not the problem. It is the naive use of next() in an
iterator that is the problem. (Note that all the examples involve calls
to next()).
Change next() rather than fiddl
40 matches
Mail list logo
