Martin v. Löwis [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schrieb:
Asyncore *only* implements asynchronous IO -- any tasks performed in
its context are the direct result of an IO operation, so it's hard to
say it implements cooperative multitasking (and Josiah can correct me if
I'm
On Thu, Feb 15, 2007 at 12:48:48AM +, Steve Holden wrote:
Given that they say a camel is a horse designed by a committee
Metaphors can go that far but not farther. And, BTW, camels are very
suited for their environments...
I am not afraid of committees for large tasks. Well, that has
I was the one on the Stackless list who last September or so
proposed the idea of monkeypatching and I'm including that
idea in my presentation for PyCon. See my early rough draft
at http://www.stackless.com/pipermail/stackless/2007-February/002212.html
which contains many details about using
On 2/14/07, Greg Ewing [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
*I* don't like the idea of something in the Python installation
deciding which reactor to use.
I wouldn't mind if some way were provided of changing
the reactor if you want. I'd just like to see a long
term goal of
On 2/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote
in response to [EMAIL PROTECTED]:
As far as I can tell, you still haven't even clearly expressed what your
needs are, let alone whether or not Twisted is suitable. In the reply
you're citing, you said that this sounded like something low
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give timing
variabilities due to CPU temperature variations even if you always eat
exactly the same thing.
Oh, great. Now we're going to have to run our
benchmarks in a temperature-controlled
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give
timing variabilities due to CPU temperature variations even if
you always eat exactly the same thing.
Oh, great. Now we're going to
[EMAIL PROTECTED] wrote:
[...]
microtreading:
Exploiting language features to use cooperative multitasking in tasks
that read like they are single-threaded.
asynchronous IO:
Performing IO to/from an application in such a way that the
application does not wait for any IO operations
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 15, 2007, at 6:27 AM, Anthony Baxter wrote:
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give
timing variabilities due to CPU
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 15, 2007, at 6:27 AM, Anthony Baxter wrote:
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give
timing
Steve Holden wrote:
Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 15, 2007, at 6:27 AM, Anthony Baxter wrote:
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give
On 2/15/07, Joachim König-Baltes [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
E.g. have a wait(events = [], timeout = -1) method would be sufficient
for most cases, where an event would specify
I agree with everything except this. A simple function call would
have O(n) cost, thus being
Adam Olsen wrote:
I agree with everything except this. A simple function call would
have O(n) cost, thus being unacceptable for servers with many open
connections. Instead you need it to maintain a set of events and let
you add or remove from that set as needed.
We can learn from kevent
On 2/15/07, Joachim König-Baltes [EMAIL PROTECTED] wrote:
Adam Olsen wrote:
I have implemented something like the above, based on greenlets.
I assume greenlets would be an internal implementation detail, not
exposed to the interface?
Yes, you could use stackless, perhaps even Twisted,
On Thu, Feb 15, 2007 at 09:19:30AM -0500, Jean-Paul Calderone wrote:
That feels like 6 layers too many, given that
_logrun(selectable, _drdw, selectable, method, dict)
return context.call({ILogContext: newCtx}, func, *args, **kw)
return self.currentContext().callWithContext(ctx, func,
On Thu, Feb 15, 2007 at 04:28:17PM +0100, Joachim K?nig-Baltes wrote:
No, I'd like to have:
- An interface for a task to specifiy the events it's interested in, and
waiting for at least one of the events (with a timeout).
- an interface for creating a task (similar to creating a thread)
Joachim König-Baltes wrote:
The problem solved by this approach is to allow a number of cooperating
threads to wait for an event without the need to busy loop or block by
delegating
the waiting to a central instance, the scheduler. How this efficient
waiting is
implemented is the
On Thu, 15 Feb 2007 10:46:05 -0500, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2007 at 09:19:30AM -0500, Jean-Paul Calderone wrote:
That feels like 6 layers too many, given that
_logrun(selectable, _drdw, selectable, method, dict)
return context.call({ILogContext: newCtx}, func,
Bob Ippolito wrote:
There is no single PerfectReactor. There are several use cases where
you need to wait on 1 different event systems, which guarantees at
least two OS threads (and two event loops). In general it's nice to
have a single Python event loop (the reactor) to act on said threads
At 11:00 PM 2/14/2007 -0600, [EMAIL PROTECTED] wrote:
Instead, I would like to concentrate on producing a small, clean,
consistent, generator-based microthreading library. I've seen several
such libraries (including the one in PEP 342, which is fairly skeletal),
and they all work *almost* the
On Thu, 15 Feb 2007 10:36:21 -0600, [EMAIL PROTECTED] wrote:
[snip]
def fetchSequence(...):
fetcher = Fetcher()
yield fetcher.fetchHomepage()
firstData = yield fetcher.fetchPage('http://...')
if someCondition(firstData):
while True:
secondData = yield
At 11:47 AM 2/15/2007 -0500, Jean-Paul Calderone wrote:
Is the only problem here that this style of development hasn't had been made
visible enough?
You betcha. I sure as heck wouldn't have bothered writing the module I
did, if I'd known it already existed. Or at least only written whatever
On 2/15/07, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
Is the only problem here that this style of development hasn't had been made
visible enough?
Perhaps not the only problem, but definitely a big part of it. I
looked for such a thing in twisted after python 2.5 came out and was
unable to
Martin v. Löwis wrote:
Now, for these generalized event loops, it may not be possible anymore
to combine all event sources into a single blocking call.
Right, that's why my proposal assumed that each disparate event source
would need its own thread.
Ah, threads :-( It turns out that you
On Thu, Feb 15, 2007 at 11:47:27AM -0500, Jean-Paul Calderone wrote:
Is the only problem here that this style of development hasn't had been made
visible enough?
Yep -- I looked pretty hard about two years ago, and although I haven't
been looking for that specifically since, I haven't heard
[EMAIL PROTECTED] wrote:
I think this discussion would be facilitated by teasing the first
bullet-point from the latter two: the first deals with async IO, while
the latter two deal with cooperative multitasking.
It's easy to write a single package that does both, but it's much harder
to
On Thu, Feb 15, 2007 at 07:46:59PM +, Nick Maclaren wrote:
[EMAIL PROTECTED] wrote:
I think this discussion would be facilitated by teasing the first
bullet-point from the latter two: the first deals with async IO, while
the latter two deal with cooperative multitasking.
It's
* Teach vars() to work with classes defining __slots__. Essentially, __slots__
are just an implementation detail designed to make instances a bit more compact.
* Make the docstring writable for staticmethods, classmethods, and properties.
We did this for function objects and it worked-out
[EMAIL PROTECTED] wrote:
Knowing the history of something like this is very helpful, but I'm not
sure what you mean by this first paragraph. I think I'm most unclear
about the meaning of The 'threading' approach to asynchronous I/O?
Its opposite (separating asynchronous I/O from threading)
[EMAIL PROTECTED] wrote:
I think this discussion would be facilitated by teasing the first
bullet-point from the latter two: the first deals with async IO, while
the latter two deal with cooperative multitasking.
It's easy to write a single package that does both, but it's much harder
to
Ah, threads :-( It turns out that you need to invoke GetMessage in the
context of the thread in which the window was created. In a different
thread, you won't get any messages.
I'd be interested to hear about other situations where threading would
cause a problem. My suspicion is that
On 2/15/07, Baptiste Carvello [EMAIL PROTECTED] wrote:
Ah, threads :-( It turns out that you need to invoke GetMessage in the
context of the thread in which the window was created. In a different
thread, you won't get any messages.
I'd be interested to hear about other situations where
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007 02:36:22 -0700, Andrew Dalke [EMAIL PROTECTED] wrote:
[snip]
2) asyncore is
smaller and easier to understand than Twisted,
While I hear this a lot, applications written with Twisted _are_ shorter and
contain less irrelevant
[EMAIL PROTECTED] wrote:
I really, really wish that every feature proposal for Python had
to meet
some burden of proof
Ben North wrote:
This is what I understood the initial posting to python-ideas to be
about.
[EMAIL PROTECTED] wrote:
I'm suggesting that the standards of the
On 2/15/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
* Add a pure python named_tuple class to the collections module. I've been
using the class for about a year and found that it greatly improves the
usability of tuples as records.
Guido van Rossum wrote:
On 2/15/07, Raymond Hettinger [EMAIL PROTECTED] wrote:
* Add a pure python named_tuple class to the collections module.
I've been using the class for about a year and found that it greatly
improves the usability of tuples as records.
Martin v. Löwis wrote:
That is insufficient. The gtk main loop has more input
sources than just the connection to X:
- timers
- idle handlers
- child handlers
- additional file descriptors
- a generalzed 'event source'
When gtk is not the central event mechanism, there's no
need to use
Hm, but why would they still have to be tuples? Why not just have a
generic 'record' class?
Tim Hmm - possibilities. record definitely has greater connotations
Tim of heterogeneous elements than tuple, which would put paid to the
Tim constant arguments that a tuple is
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a committee.
Camels are very good at surviving in the desert, but not so good at
winning a
[EMAIL PROTECTED] wrote:
Hm, but why would they still have to be tuples? Why not just
have a generic 'record' class?
Tim Hmm - possibilities. record definitely has greater
connotations Tim of heterogeneous elements than tuple, which
would put paid to the Tim constant
Greg Ewing wrote:
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a
committee. Camels are very good at surviving in the desert, but not
Anthony Baxter wrote:
Unless the fans are perfectly balanced, small changes in gravity are
going to affect the rate at which they spin. So I guess the
position of the moon will affect it :-)
A standard gravitational field could also be important
to eliminate relativistic effects.
So we
On Friday 16 February 2007 09:08, Ben North wrote:
Instead of new syntax, a new wrapper class was proposed,
with the following specification / conceptual implementation
suggested by Martin Loewis:
...snip...
This was considered a cleaner and more elegant solution to
the original
Greg Ewing wrote:
Oleg Broytmann wrote:
Given that they say a camel is a horse designed by a committee
BTW, camels are very suited for their environments...
The quote is actually a camel is a *racehorse* designed by a committee.
Camels are very good at surviving in the desert, but not so
On Thu, Feb 15, 2007 at 05:41:51PM -0600, [EMAIL PROTECTED] wrote:
Tim Hmm - possibilities. record definitely has greater connotations
Tim of heterogeneous elements than tuple, which would put paid to the
Tim constant arguments that a tuple is really just an immutable list.
(What
[Raymond Hettinger]
* Add a pure python named_tuple class to the collections module.
I've been using the class for about a year and found that it greatly
improves the usability of tuples as records.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
[Delaney, Timothy]
Hmm -
On 15/02/2007 20.59, Raymond Hettinger wrote:
* Add a pure python named_tuple class to the collections module. I've been
using the class for about a year and found that it greatly improves the
usability of tuples as records.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
On Thu, 15 Feb 2007 13:55:31 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
[snip]
Now if we can only figure out a way for everyone to benefit from this without
tying too many brains up in knots. :)
Whenever I need to deal with these kinds of
On 2/15/07, Anthony Baxter [EMAIL PROTECTED] wrote:
On Friday 16 February 2007 09:08, Ben North wrote:
The wrapper class idea was left
open as a possibility for a future PEP.
A good first step would be to contribute something like this to the
Python Cookbook, if it isn't already there.
I
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007 13:55:31 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
[snip]
Now if we can only figure out a way for everyone to benefit from this
without
tying too many brains up in
50 matches
Mail list logo
