On Nov 27, 2014, at 8:52 AM, Guido van Rossum gu...@python.org 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
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
On 27 November 2014 at 11:15, Guido van Rossum gu...@python.org wrote:
On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 27 Nov 2014 06:35, Guido van Rossum gu...@python.org wrote:
[...]
I think we can put a number to much faster now -- 150 nsec per
try/except.
On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 27 November 2014 at 11:15, Guido van Rossum gu...@python.org wrote:
On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan ncogh...@gmail.com
wrote:
On 27 Nov 2014 06:35, Guido van Rossum gu...@python.org wrote:
[...]
On 28 November 2014 at 02:52, Guido van Rossum gu...@python.org wrote:
On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
If compatibility with older Python versions is needed, then you could
put something like the following in a compatibility module:
try:
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
On 26 November 2014 at 18:30, Greg Ewing greg.ew...@canterbury.ac.nz 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
On 26 November 2014 at 21:44, Petr Viktorin encu...@gmail.com wrote:
On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
Now needs to be written out explicitly as:
def my_generator():
...
try:
yield next(it)
except StopIteration
On Wed, Nov 26, 2014 at 10:24 PM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 26 November 2014 at 18:30, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
On Thu, Nov 27, 2014 at 2:55 AM, Hrvoje Niksic hrvoje.nik...@avl.com 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
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 (attempting to
On Wed, Nov 26, 2014 at 3:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 26 November 2014 at 18:30, Greg Ewing greg.ew...@canterbury.ac.nz
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.
On 27 Nov 2014 06:35, Guido van Rossum gu...@python.org wrote:
On Wed, Nov 26, 2014 at 3:24 AM, Nick Coghlan ncogh...@gmail.com 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
On Thu, Nov 27, 2014 at 9:53 AM, Nick Coghlan ncogh...@gmail.com 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
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 ros...@gmail.com wrote:
On Thu, Nov 27, 2014 at 9:53 AM, Nick Coghlan
On Thu, Nov 27, 2014 at 11:33 AM, Guido van Rossum gu...@python.org 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
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 ros...@gmail.com wrote:
On Thu, Nov 27, 2014 at 11:33 AM, Guido van
On Thu, Nov 27, 2014 at 11:50 AM, Guido van Rossum gu...@python.org 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
Well, that's just a general problem with decorator ordering.
On Wed, Nov 26, 2014 at 4:57 PM, Chris Angelico ros...@gmail.com wrote:
On Thu, Nov 27, 2014 at 11:50 AM, Guido van Rossum gu...@python.org
wrote:
No, that was a figure of speech. The proposed decorator returns a new
function
On Thu, Nov 27, 2014 at 12:01 PM, Guido van Rossum gu...@python.org 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
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
On Thu, Nov 27, 2014 at 12:11 PM, Guido van Rossum gu...@python.org 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.
On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 27 Nov 2014 06:35, Guido van Rossum gu...@python.org 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
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
On Tue, Nov 25, 2014 at 4:58 PM, Greg greg.ew...@canterbury.ac.nz 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
On Wed, Nov 26, 2014 at 11:58 AM, Greg greg.ew...@canterbury.ac.nz 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
On 11/23/14, Guido van Rossum wrote:
It wouldn#39;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 next()
On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher ischwabac...@wisc.edu
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
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 if we had the occasional generator author writing
raise StopIteration instead
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
ischwabac...@wisc.edu(javascript:main.compose() wrote:
On 11/23/14, Guido van Rossum wrote:
It wouldn't be so
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') target=1ischwabac...@wisc.edu wrote:
On 11/24/14, Guido van Rossum wrote:
On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher
On Mon, Nov 24, 2014 at 3:07 PM, Isaac Schwabacher ischwabac...@wisc.edu
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') target=1
ischwabac...@wisc.edu wrote:
On 11/24/14, Guido van Rossum
On 25 November 2014 at 10:47, Guido van Rossum gu...@python.org 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
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
On Mon, Nov 24, 2014 at 7:18 AM, Mark Shannon m...@hotpy.org 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
On 23/11/14 22:54, Chris Angelico wrote:
On Mon, Nov 24, 2014 at 7:18 AM, Mark Shannon m...@hotpy.org 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
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
On 11/23/14, Mark Shannon m...@hotpy.org 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
40 matches
Mail list logo
