Nick Coghlan wrote:
Phillip J. Eby wrote:
Nick Coghlan wrote:
[...]
Last, but far from least, as far as I can tell you can implement all of
these semantics using PEP 342 as it sits. That is, it's very simple to
make decorators or classes that add those semantics. I don't see
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
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
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,
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 anywhere they
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 benchmark
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,
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 3.4.4)
In my
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 would continue to exist
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).
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, especially
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, 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_cmd_line on Kubuntu 5.10
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, how about
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
semantics of
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
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 for
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 StopIteration
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
inside
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: it's _not currently
20 matches
Mail list logo
