Hello,
Following recent discussion of keeping Windows matters to the main dev
list, I hope this message will be found useful. Please note that this
is not a bug report, mostly a FYI.
So, I tried to install Python 3.4.2 on an Intel Galileo board shipped
with Windows For Devices. Actually, I don't
On Thu, Nov 27, 2014 at 8:57 AM, Isaac Schwabacher
wrote:
>> Can you summarize that in a self-contained form for inclusion in the PEP?
>>
>> (That was a rhetorical question. :-)
>
> Sure. Is it on GitHub? ;D
Thanks Isaac, I've incorporated your edits.
https://raw.githubusercontent.com/Rosuav/Gen
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
> Can you summarize that in a self-contained form for inclusion in the PEP?
>
> (That was a rhetorical question. :-)
Sure. Is it on GitHub? ;D
ijs
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Uns
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 Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan wrote:
>
> On 27 Nov 2014 03:58, "Paul Moore" wrote:
> >
> > On 26 November 2014 at 17:19, Guido van Rossum wrote:
> > > It's hard to use as an example because the behavior of contextlib is an
> > > integral part of it -- currently for me the exampl
You can use the README here: https://github.com/Rosuav/GenStopIter
On Wed, Nov 26, 2014 at 1:57 PM, Isaac Schwabacher
wrote:
> > Can you summarize that in a self-contained form for inclusion in the PEP?
> >
> > (That was a rhetorical question. :-)
>
> Sure. Is it on GitHub? ;D
>
> ijs
>
--
-
On 27 Nov 2014 03:58, "Paul Moore" wrote:
>
> On 26 November 2014 at 17:19, Guido van Rossum wrote:
> > It's hard to use as an example because the behavior of contextlib is an
> > integral part of it -- currently for me the example boils down to
"there is
> > a bug in contextlib"
>
> Hmm, fair po
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 14-11-26, Guido van Rossum wrote:
> On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
>
> > On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
> > > This actually leads to a good example of why the PEP is necessary:
> > [...]
> >
> > Oh! If that's the current behaviour, then it probably
Can you summarize that in a self-contained form for inclusion in the PEP?
(That was a rhetorical question. :-)
On Wed, Nov 26, 2014 at 12:17 PM, Isaac Schwabacher
wrote:
> On 14-11-26, Guido van Rossum wrote:
> > On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
> >
> > > On 26 November 2014
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
I'm pleased to announce the first release candidate of Python 2.7.9,
which will be the next bugfix release in the Python 2.7 series. Despite
technically being a maintenance release, Python 2.7.9 will include
several majors changes from 2.7.8:
- The "ensurepip" module has been backported to Python 2
On 11/26/2014 08:54 AM, Paul Moore wrote:
> On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
>> This actually leads to a good example of why the PEP is necessary:
> [...]
>
> Oh! If that's the current behaviour, then it probably needs to go into
> the PEP as a motivating example. It's far m
On 26 November 2014 at 17:19, Guido van Rossum wrote:
> It's hard to use as an example because the behavior of contextlib is an
> integral part of it -- currently for me the example boils down to "there is
> a bug in contextlib"
Hmm, fair point. I was assuming that the bug in contextlib can't be
On Wed, Nov 26, 2014 at 8:54 AM, Paul Moore wrote:
> On 26 November 2014 at 16:24, Isaac Schwabacher
> wrote:
> > This actually leads to a good example of why the PEP is necessary:
> [...]
>
> Oh! If that's the current behaviour, then it probably needs to go into
> the PEP as a motivating exampl
On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
> This actually leads to a good example of why the PEP is necessary:
[...]
Oh! If that's the current behaviour, then it probably needs to go into
the PEP as a motivating example. It's far more convincing than most of
the other arguments I've
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 11/26/14, Nick Coghlan wrote:
> On 26 November 2014 at 04:04, Guido van Rossum wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico wrote:
> >>
> >> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> >> wrote:
> >> > Yield can also raise StopIteration, if it's thrown in. The current
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 11/26/14, Nick Coghlan wrote:
> On 26 November 2014 at 04:04, Guido van Rossum wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico wrote:
> >>
> >> On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
> >> wrote:
> >> > Yield can also raise StopIteration, if it's thrown in. The current
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
35 matches
Mail list logo
