On 8/02/2009 10:21 AM, Antoine Pitrou wrote:
Mark Hammond gmail.com> writes:
I'm not sure if the following is a bug I should report or simply an
artifact of the implementation and/or simply the way things work on py3k:
[...]
It's a bug.
http://bugs.python.org/issue5182
Cheers,
Mark
On 01:00 am, greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
We already have yield expressions and they mean something else...
They don't have a "*" in them, though, and I don't
think the existing meaning of yield as an expression
would carry over into the "yield *" variant, so the
Guido van Rossum wrote:
We already have yield expressions and they mean something else...
They don't have a "*" in them, though, and I don't
think the existing meaning of yield as an expression
would carry over into the "yield *" variant, so there
shouldn't be any conflict.
But if you think th
Mark Hammond gmail.com> writes:
>
>I'm not sure if the following is a bug I should report or simply an
> artifact of the implementation and/or simply the way things work on py3k:
> [...]
It's a bug.
Regards
Antoine.
___
Python-Dev mailing list
Hi all,
I'm not sure if the following is a bug I should report or simply an
artifact of the implementation and/or simply the way things work on py3k:
% py30 -c "str(memoryview(bytearray((1,2,3"
Traceback (most recent call last):
File "", line 1, in
TypeError: __str__ returned non-strin
Time to move to this to python-ideas, folks.
On Sat, Feb 7, 2009 at 12:26 PM, Calvin Spealman wrote:
> All of this debate is moot without the foundation of a common library
> on which we would be building these coroutines. Any proposal of a
> specific coroutine syntax is worthless without a time
All of this debate is moot without the foundation of a common library
on which we would be building these coroutines. Any proposal of a
specific coroutine syntax is worthless without a time and community
tested coroutine implementation, which would be subject to the same
rigerous inclusion requirem
Willem Broekema wrote:
Function g violates the current limitation that generators can't
return with a value. So can g only be used using "yield *" then, or
would that limitation be removed?
The limitation would be removed, in the interests
of making it easier to use generators as coroutines.
I have a small change (shown below) to PyShell.py in idlelib that
causes the subprocess interpreter to read IDLESTARTUP or
PYTHONSTARTUP each time it restarts. To me this would make IDLE much
more useful for myself and students I teach. It isn't quite clear
what behavior to install with the en
We already have yield expressions and they mean something else...
On Sat, Feb 7, 2009 at 1:04 AM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> It would be way too confusing to have "a different form of call" with
>> totally different semantics that nevertheless used the same
>> *terminology*
On Sat, Feb 7, 2009 at 9:41 AM, Curt Hagenlocher wrote:
> On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum wrote:
>> On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher
>> wrote:
>>> ...because they're not quite :). Should I file this as a bug report?
>>
>> No, this is just how it works. I hope t
On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum wrote:
> On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher wrote:
>> ...because they're not quite :). Should I file this as a bug report?
>
> No, this is just how it works. I hope they aren't documented as immuable?
Not that I know of :). But the
On Sat, Feb 7, 2009 at 10:04 AM, Greg Ewing wrote:
> def f():
>v = yield *g()
>print v
>
> def g():
>yield 42
>return "spam"
Function g violates the current limitation that generators can't
return with a value. So can g only be used using "yield *" then, or
would that limitation
Guido van Rossum wrote:
It would be way too confusing to have "a different form of call" with
totally different semantics that nevertheless used the same
*terminology* as is used for regular calls.
I expect you're right, so I won't argue for calling
it "call" any more.
I'd still like to find
On Fri, Feb 6, 2009 at 11:38 PM, Lisandro Dalcin wrote:
> Done, http://bugs.python.org/issue5175
Thank you!
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
15 matches
Mail list logo
