James Y Knight wrote:
>
> On Oct 8, 2005, at 9:10 PM, Nick Coghlan wrote:
>
>> So, instead of having "return" automatically map to "raise
>> StopIteration"
>> inside generators, I'd like to suggest we keep it illegal to use
>> "return"
>> inside a generator
>
>
> Only one issue with that: i
On Oct 8, 2005, at 9:10 PM, Nick Coghlan wrote:
> So, instead of having "return" automatically map to "raise
> StopIteration"
> inside generators, I'd like to suggest we keep it illegal to use
> "return"
> inside a generator
Only one issue with that: it's _not currently illegal_ to use return
Guido van Rossum wrote:
> On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>So, instead of having "return" automatically map to "raise StopIteration"
>>inside generators, I'd like to suggest we keep it illegal to use "return"
>>inside a generator, and instead add a new attribute "result" to Sto
> Guido van Rossum wrote:
> > Before we do this I'd like to see you show some programming examples
> > that show how this would be used. I'm having a hard time understanding
> > where you would need this but I realize I haven't used this paradigm
> > enough to have a good feel for it, so I'm open f
Josiah Carlson wrote:
> I do, however, doubt that free threading approaches will be the future
> for concurrent programming in CPython.
Hear, hear! IMO, it's the combination of the GIL with a compiler which never
decides to change the code execution order under the covers that makes
threading *n
Guido van Rossum wrote:
>>This change would make a huge difference to the practical usability of these
>>generator-based tasks. I think they're much less likely to catch on if you
>>have to write "raise StopIteration( Result )" (or "_return( Result )") all the
>>time.
>>
>>[1] a.k.a. coroutines, w
On 10/7/05, Piet Delport <[EMAIL PROTECTED]> wrote:
> Earlier this week, i proposed legalizing "return Result" inside a generator,
> and making it act like "raise StopIteration( Result )", for exactly this
> reason.
>
> IMHO, this is an elegant and straightforward extension of the current
> semant
Bruce Eckel <[EMAIL PROTECTED]> wrote:
>
> > I can (but won't) point out examples for days of bad decisions made for
> > the sake of speed, or policy that has been ignored for the sake of speed
> > (some of these overlap and some don't).
>
> As long as you've entered premature-optimization land,
On 10/8/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Hye-Shik Chang wrote:
> > > On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > >
> > >>Anyone else seeing any problems with test_cmd_line? I've got a few
> > >>failures in
> > >>test_
> I can (but won't) point out examples for days of bad decisions made for
> the sake of speed, or policy that has been ignored for the sake of speed
> (some of these overlap and some don't).
As long as you've entered premature-optimization land, how about
decisions made because it's *assumed* that
On 10/8/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Your malicious user is my inventive colleague. Here's one: performing
> zero-copy inter-thread IPC by modifying shared immutables. Attempting to
> enforce a policy of "don't do that, it's not supported" is not going to
> be effective, especia
On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Hye-Shik Chang wrote:
> > On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >
> >>Anyone else seeing any problems with test_cmd_line? I've got a few failures
> >>in
> >>test_cmd_line on Kubuntu 5.10 with GCC 4.0 relating to a missing "\n" l
Michael Sparks <[EMAIL PROTECTED]> wrote:
> On Saturday 08 October 2005 04:05, Josiah Carlson wrote:
> > I'm just offering the above as example benchmarks (you certainly don't
> > need to do them to satisfy me, but I'll be doing those when my tuple
> > space implementation is closer to being done)
Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > I need to stress that *only* the new, immutable and "thread-safe
> > > mark-and-sweep" types would be affected by these changes. Everything
> > > else woul
Hye-Shik Chang wrote:
> On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>Anyone else seeing any problems with test_cmd_line? I've got a few failures in
>>test_cmd_line on Kubuntu 5.10 with GCC 4.0 relating to a missing "\n" line
>>ending.
>>
>
>
> Same problem here. (FreeBSD 6.0 with GCC
On 10/8/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Anyone else seeing any problems with test_cmd_line? I've got a few failures in
> test_cmd_line on Kubuntu 5.10 with GCC 4.0 relating to a missing "\n" line
> ending.
>
Same problem here. (FreeBSD 6.0 with GCC 3.4.4)
In my short inspection, pop
On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I need to stress that *only* the new, immutable and "thread-safe
> > mark-and-sweep" types would be affected by these changes. Everything
> > else would continue to exist as it did before, and the b
On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:17 PM 10/7/2005 -0600, Adam Olsen wrote:
> >On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Note that implementing a root-based GC for Python is non-trivial, since
> > > extension modules can store pointers to PyObjects anywh
On Saturday 08 October 2005 04:05, Josiah Carlson wrote:
[ simplistic, informal benchmark of a test optimised versioned of the system,
based on bouncing scaing rotating sprites around the screen. ]
> Single process? Multi-process single machine? Multiprocess multiple
> machine?
SIngle process,
What happened to the CurrentVersion registry entry documented at
http://www.python.org/windows/python/registry.html
AFAICT, even the python15.wse file did not fill a value in this
entry (perhaps I'm misinterpreting the wse file, though).
So was this ever used? Why is it documented, and who docum
Anyone else seeing any problems with test_cmd_line? I've got a few failures in
test_cmd_line on Kubuntu 5.10 with GCC 4.0 relating to a missing "\n" line
ending.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
21 matches
Mail list logo
