"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Larry Hastings schrieb:
> > Oof! I'm embarrassed to have forgotten that. But that's not a fatal
> > problem. It means that on Windows the PerfectReactor must service the
> > blocking GetMessage loop, and these other threads notify the
> > Per
Raymond Hettinger schrieb:
> No need to go so widely off-track. The idea is to have an efficient type
> that
> is directly substitutable for tuples but is a bit more self-descriptive. I
> like
> to have the doctest result cast at NamedTuple('TestResults failed attempted).
> The repr of that
Larry Hastings schrieb:
> Oof! I'm embarrassed to have forgotten that. But that's not a fatal
> problem. It means that on Windows the PerfectReactor must service the
> blocking GetMessage loop, and these other threads notify the
> PerfectReactor of new events by sending a message.
...
> I'd
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
> >> tyin
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 t
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
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/50026
[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]
>
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
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
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 o
Nick Maclaren wrote:
> Threading
> -
>
> An I/O operation passes a buffer, length, file and action and receives a
> token back.
You seem to be using the word "threading" in a completely
different way than usual here, which may be causing some
confusion.
--
Greg
_
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 n
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 d
[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 th
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
winni
>> 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 tup
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
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.
>> http://aspn.activestate
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.
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recip
[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
> On Thu, 15 Feb 2007 10:46:05 -0500, "A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
> >It's hard to debug the resulting problem. Which level of the *12*
> >levels in the stack trace is responsible for a bug? Which of the *6*
> >generic calls is calling the wrong thing because a handler was set up
>
I've sent an updated version of PEP 363 to the editors, which
includes the following summary of the discussion. I hope I've
captured the important points, but please let me know if there's
something important I've left out or misrepresented.
- - - - 8< - - - -
Mailing Lists Discussion
Initi
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 i
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 situ
>> 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
[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
>
> On 2/15/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> I would like to be the one to migrate it to Py3.0.
[Steve]
> No complaints here. Not that you need my permission of course. ;-)
Thanks, I had already started working on this one.
Of course, everyone is welcome to contribute.
Raymond
[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 threa
* 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 well.
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.
> >
[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
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 an
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 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
On 2/15/07, Joachim König-Baltes <[EMAIL PROTECTED]> wrote:
> Adam Olsen schrieb:
> > I don't think we're on the same page then. The way I see it you want
> > a single async IO implementation shared by everything while having a
> > collection of event loops that cooperate "just enough". The async
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 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 fetcher.fetchPage(
On Thu, Feb 15, 2007 at 04:51:30PM +0100, Joachim K?nig-Baltes wrote:
> The style used in asyncore, inheriting from a class and calling return
> in a method
> and being called later at a different location (different method) just
> interrupts the
> sequential flow of operations and makes it harde
Larry Hastings schrieb:
> 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 ("th
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
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 thr
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: new
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 resp
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 threa
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
Adam Olsen schrieb:
> I don't think we're on the same page then. The way I see it you want
> a single async IO implementation shared by everything while having a
> collection of event loops that cooperate "just enough". The async IO
> itself would likely end up being done in C.
>
No, I'd like to
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
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 h
On Thu, 15 Feb 2007 02:36:22 -0700, Andrew Dalke <[EMAIL PROTECTED]> wrote:
>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/
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 bei
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
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
-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 C
[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 ope
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 w
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-cont
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
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
> ter
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 Stac
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
"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 m
62 matches
Mail list logo
