On 02:28 am, s...@pobox.com wrote:
Glyph ... which is exactly why I have volunteered to explain to
someone
Glyph how to separate the core event-loop bits
Neil This sounds great.
Anybody interested in working on this at a PyCon Sprint? I won't be
attending the conference proper,
On 01:50 am, n...@arctrix.com wrote:
gl...@divmod.com gl...@divmod.com wrote:
we're not even talking about actually putting any Twisted code
into the standard library, just standardizing the protocol API,
which
basically boils down to:
[...]
This sounds great. I'm interested on working
Glyph I'll try to make sure we get those notes to you in advance of the
Glyph sprints :). I should be at the Twisted sprint the whole time -
Glyph will you be at the physical sprint, or following along at home?
Thanks. I will be at the physical sprints. (I live in the Chicago
On Sat, Mar 7, 2009 at 8:28 PM, s...@pobox.com wrote:
Anybody interested in working on this at a PyCon Sprint? I won't be
attending the conference proper, but plan to spend a couple days sprinting,
I'll be there and interested. :)
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises,
On 02:46 pm, dan...@stutzbachenterprises.com wrote:
On Sat, Mar 7, 2009 at 8:28 PM, s...@pobox.com wrote:
Anybody interested in working on this at a PyCon Sprint? I won't be
attending the conference proper, but plan to spend a couple days
sprinting,
I'll be there and interested. :)
gl...@divmod.com gl...@divmod.com wrote:
... which is exactly why I have volunteered to explain to someone how to
separate the core event-loop bits (suitable for inclusion in the
standard library) from the huge pile of protocol implementations which
are not necessarily useful.
Despite the
Glyph ... which is exactly why I have volunteered to explain to someone
Glyph how to separate the core event-loop bits (suitable for inclusion
Glyph in the standard library) from the huge pile of protocol
Glyph implementations which are not necessarily useful.
Neil This sounds
Greg Ewing wrote:
Antoine Pitrou wrote:
For starters, since py3k is supposed to support non-blocking IO, why not write a
portable API to make a raw file or socket IO object non-blocking?
I think we need to be clearer what we mean when we talk
about non-blocking in this context. Normally when
Hrvoje Niksic wrote:
Under Linux, select() may report a socket file descriptor
as ready for reading, while nevertheless
a subsequent read blocks.
Blarg. Linux is broken, then. This should not happen.
This could for example
happen when data has arrived
Greg Ewing wrote:
Even if you don't agree that using O_NONBLOCK with select/poll is the
best approach to non-blocking, I think there is enough existing practice
of doing this to warrant separate consideration of non-blocking sockets
(in the OS sense) and select/poll.
I'm not saying there
On 10:01 am, greg.ew...@canterbury.ac.nz wrote:
Hrvoje Niksic wrote:
Under Linux, select() may report a socket file descriptor
as ready for reading, while nevertheless
a subsequent read blocks.
Blarg. Linux is broken, then. This should not happen.
You know what else
On 4 Mar, 09:14 pm, krs...@solarsail.hcs.harvard.edu wrote:
I spent about a half hour sometime in the last month talking this
through with Itamar, though not in great detail. I'd be interested in
sitting down with both of you and trying to establish more precisely
how much work is necessary to
On 4 Mar, 08:28 pm, ba...@python.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 4, 2009, at 2:44 PM, gl...@divmod.com wrote:
Maintaining compatibility with the 2.6.x version of asyncore
presupposes that *someone* has written some software against that
version of asyncore and
On 4 Mar, 09:36 pm, dan...@stutzbachenterprises.com wrote:
Will any or all of you be at PyCon? I'd be willing to put in the extra
work
to turn your notes into a PEP.
I definitely will be. I'll see you there!
___
Python-Dev mailing list
Chris McDonough chr...@plope.com wrote:
As far as I can tell, asyncore/asynchat is all undocumented
internals. Any use of asyncore in anger will use internals;
there never was any well-understood API to these modules.
What I would like to see is a module that provides a low-level API
for
On Thu, Mar 5, 2009 at 1:30 PM, Neil Schemenauer n...@arctrix.com wrote:
What I would like to see is a module that provides a low-level API
for doing cross-platform asynchronous IO. The two necessary parts
are:
* a wrapper that allows non-blocking reads and writes on
channels
Neil Schemenauer wrote:
What I would like to see is a module that provides a low-level API
for doing cross-platform asynchronous IO. The two necessary parts
are:
* a wrapper that allows non-blocking reads and writes on
channels (sockets, file descriptors, serial ports, etc)
*
Daniel Stutzbach wrote:
If you have a working select(), it will tell you the sockets on which
read() and write() won't block, so non-blocking reads and writes are not
necessary.
No, but there should be an interface that lets you say
when something comes in on this fd, call this function
for
On Thu, Mar 5, 2009 at 12:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Daniel Stutzbach wrote:
If you have a working select(), it will tell you the sockets on which
read() and write() won't block, so non-blocking reads and writes are not
necessary.
No, but there should be an
Josiah Carlson josiah.carl...@gmail.com wrote:
On Thu, Mar 5, 2009 at 12:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Daniel Stutzbach wrote:
If you have a working select(), it will tell you the sockets on which
read() and write() won't block, so non-blocking reads and writes
Josiah Carlson wrote:
A read callback, a write callback. What about close, error, connect,
and accept callbacks?
Yep, all those as well.
I hate to say it (not really), but that's pretty much the handle_*()
methods of asyncore :/ .
Well, then, what's the problem?
Is there anything else
On Thu, Mar 5, 2009 at 1:09 PM, Bill Janssen jans...@parc.com wrote:
Josiah Carlson josiah.carl...@gmail.com wrote:
On Thu, Mar 5, 2009 at 12:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Daniel Stutzbach wrote:
If you have a working select(), it will tell you the sockets on
Greg Ewing greg.ewing at canterbury.ac.nz writes:
Neil Schemenauer wrote:
What I would like to see is a module that provides a low-level API
for doing cross-platform asynchronous IO. The two necessary parts
are:
* a wrapper that allows non-blocking reads and writes on
On 07:30 pm, n...@arctrix.com wrote:
Chris McDonough chr...@plope.com wrote:
As far as I can tell, asyncore/asynchat is all undocumented
internals. Any use of asyncore in anger will use internals;
there never was any well-understood API to these modules.
The implementation requires some
On Thu, Mar 5, 2009 at 3:11 PM, gl...@divmod.com wrote:
On 07:30 pm, n...@arctrix.com wrote:
Chris McDonough chr...@plope.com wrote:
As far as I can tell, asyncore/asynchat is all undocumented
internals. Any use of asyncore in anger will use internals;
there never was any well-understood
Antoine Pitrou wrote:
For starters, since py3k is supposed to support non-blocking IO, why not write a
portable API to make a raw file or socket IO object non-blocking?
I think we need to be clearer what we mean when we talk
about non-blocking in this context. Normally when you're
using
On Tue, Mar 3, 2009 at 9:31 PM, gl...@divmod.com wrote:
On 3 Mar, 10:20 pm, gu...@python.org wrote:
On Tue, Mar 3, 2009 at 1:17 PM, gl...@divmod.com wrote:
At the very least, this might serve as a basis for an abstract API for
asyncore:
On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum gu...@python.org wrote:
Sounds like it's not so much the code that's future proof but the
process used for evolving it. That seems to be missing for asyncore.
:-(
Turning the issue around a bit, has anyone considered polishing up the
current fix
On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
sidnei.da.si...@gmail.com wrote:
On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum gu...@python.org wrote:
Sounds like it's not so much the code that's future proof but the
process used for evolving it. That seems to be missing for asyncore.
:-(
On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum gu...@python.org wrote:
On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
sidnei.da.si...@gmail.com wrote:
On Wed, Mar 4, 2009 at 3:04 PM, Guido van Rossum gu...@python.org wrote:
Sounds like it's not so much the code that's future proof but
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone exar...@divmod.com wrote:
- Show quoted text -
On Wed, 4 Mar 2009 10:21:26 -0800, Guido van Rossum gu...@python.org
wrote:
On Wed, Mar 4, 2009 at 10:14 AM, Sidnei da Silva
sidnei.da.si...@gmail.com wrote:
On Wed, Mar 4, 2009 at 3:04 PM,
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum gu...@python.org wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone exar...@divmod.com wrote:
[snip]
So, as a disinterested party in this specific case, I'd say revert to
the pre-2.6 behavior. It does less harm than leaving the
On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone exar...@divmod.com wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum gu...@python.org
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone exar...@divmod.com
wrote:
[snip]
So, as a disinterested party in this specific
On Wed, 4 Mar 2009 10:54:19 -0800, Guido van Rossum gu...@python.org wrote:
On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone exar...@divmod.com wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum gu...@python.org
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone
Guido van Rossum wrote:
On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone exar...@divmod.com
wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum gu...@python.org
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone exar...@divmod.com
wrote:
[snip]
So, as a disinterested
On 06:51 pm, exar...@divmod.com wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum gu...@python.org
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone
exar...@divmod.com wrote:
So, as a disinterested party in this specific case, I'd say revert to
the pre-2.6 behavior.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 4, 2009, at 2:44 PM, gl...@divmod.com wrote:
Maintaining compatibility with the 2.6.x version of asyncore
presupposes that *someone* has written some software against that
version of asyncore and it might break if they installed an
Guido van Rossum gu...@python.org wrote:
On Wed, Mar 4, 2009 at 10:51 AM, Jean-Paul Calderone exar...@divmod.com
wrote:
On Wed, 4 Mar 2009 10:46:28 -0800, Guido van Rossum gu...@python.org
wrote:
On Wed, Mar 4, 2009 at 10:27 AM, Jean-Paul Calderone exar...@divmod.com
wrote:
[snip]
On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum gu...@python.org wrote:
The same as always. We don't change APIs in bugfix releases.
This question is actually for the Zope folks and others who have had
problems with the 2.6 asyncore/asynchat:
Are any of the problems due to a change in the
Glyph,
On Mar 4, 2009, at 12:31 AM, gl...@divmod.com wrote:
If someone who has PEP-writing skills and some free time is updating
asyncore to be more modern, I'd be very happy to walk that person
through Twisted's API design and explain how either portions of our
implementation could be
Daniel Stutzbach wrote:
On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum gu...@python.org wrote:
The same as always. We don't change APIs in bugfix releases.
This question is actually for the Zope folks and others who have had
problems with the 2.6 asyncore/asynchat:
Are any of the
On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough chr...@plope.com wrote:
Daniel Stutzbach wrote:
On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum gu...@python.org wrote:
The same as always. We don't change APIs in bugfix releases.
This question is actually for the Zope folks and others who
On Wed, Mar 4, 2009 at 3:14 PM, Ivan Krstić
krs...@solarsail.hcs.harvard.edu wrote:
I spent about a half hour sometime in the last month talking this through
with Itamar, though not in great detail. I'd be interested in sitting down
with both of you and trying to establish more precisely how
Daniel Stutzbach wrote:
On Wed, Mar 4, 2009 at 3:14 PM, Ivan Krstić
krs...@solarsail.hcs.harvard.edu
mailto:krs...@solarsail.hcs.harvard.edu wrote:
I spent about a half hour sometime in the last month talking this
through with Itamar, though not in great detail. I'd be interested
On Wed, Mar 4, 2009 at 1:31 PM, Guido van Rossum gu...@python.org wrote:
On Wed, Mar 4, 2009 at 1:27 PM, Chris McDonough chr...@plope.com wrote:
Daniel Stutzbach wrote:
On Wed, Mar 4, 2009 at 12:54 PM, Guido van Rossum gu...@python.org wrote:
The same as always. We don't change APIs in bugfix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Guido van Rossum wrote:
On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen jans...@parc.com wrote:
Josiah Carlson josiah.carl...@gmail.com wrote:
But yes, zope needs to be changed to reflect the updated
asyncore/asynchat semantics.
On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver tsea...@palladion.com wrote:
How is anybody supposed to
write a package which sits atop a library like asyncore in a fashion
portable across Python versions? The changes to the implementation in
2.6 (there is no real API) can't be reconciled,
On 08:46 pm, gu...@python.org wrote:
This seems to be the crux of the problem with asyncore, ever since it
was added to the stdlib -- there's no real API, so every change
potentially breaks something. I wish we could start over with a proper
design under a new name.
Might I suggest reactor...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
On Tue, Mar 3, 2009 at 12:23 PM, Tres Seaver tsea...@palladion.com wrote:
How is anybody supposed to
write a package which sits atop a library like asyncore in a fashion
portable across Python versions? The changes to the
On Tue, Mar 3, 2009 at 1:17 PM, gl...@divmod.com wrote:
On 08:46 pm, gu...@python.org wrote:
This seems to be the crux of the problem with asyncore, ever since it
was added to the stdlib -- there's no real API, so every change
potentially breaks something. I wish we could start over with a
On 3 Mar, 10:20 pm, gu...@python.org wrote:
On Tue, Mar 3, 2009 at 1:17 PM, gl...@divmod.com wrote:
At the very least, this might serve as a basis for an abstract API for
asyncore:
http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html
I hope we have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen [EMAIL PROTECTED] wrote:
Josiah Carlson [EMAIL PROTECTED] wrote:
But yes, zope needs to be changed to reflect the updated
asyncore/asynchat semantics. Trust me; it's faster,
I am working on getting Zope to run (or at least, start) with Python
2.6. It actually starts right now after applying some patches, which
is amazing on itself, but it dies right away due to changes in
asyncore that break Zope's internal version of medusa.
I've opened a bug against Zope on
Sidnei da Silva [EMAIL PROTECTED] wrote:
https://bugs.edge.launchpad.net/zope2/+bug/280020
I think there are real issues here with both asynchat and Medusa.
Asynchat has been heavily re-written, and the ac_out_buffer has
apparently disappeared. But ac_out_buffer_size is still there. That
On Wed, Oct 8, 2008 at 10:30 AM, Bill Janssen [EMAIL PROTECTED] wrote:
Sidnei da Silva [EMAIL PROTECTED] wrote:
https://bugs.edge.launchpad.net/zope2/+bug/280020
I think there are real issues here with both asynchat and Medusa.
Asynchat has been heavily re-written, and the ac_out_buffer has
On Wed, Oct 8, 2008 at 6:26 PM, Josiah Carlson [EMAIL PROTECTED] wrote:
ac_out_buffer was removed because it is unneeded (we have a deque; why
rely on an extra attribute?).
ac_out_buffer_size still remains as a blocksize in which to pre-split
outgoing data (if you have a 100k string you want
Sidnei da Silva [EMAIL PROTECTED] wrote:
Great to know. So medusa should be changed similarly to the changes
made to asynchat?
Hmmm. Been a long time since a Medusa release, but I need a working
Medusa, too.
Your suggestion on the bugtracker is even better: to
subclass asynchat as much as
Josiah Carlson [EMAIL PROTECTED] wrote:
But yes, zope needs to be changed to reflect the updated
asyncore/asynchat semantics. Trust me; it's faster, cleaner, and
easier to use now.
Just for completeness, I built a fresh 2.6, installed Medusa (from
http://www.amk.ca/python/code/medusa.html),
On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen [EMAIL PROTECTED] wrote:
Josiah Carlson [EMAIL PROTECTED] wrote:
But yes, zope needs to be changed to reflect the updated
asyncore/asynchat semantics. Trust me; it's faster, cleaner, and
easier to use now.
Just for completeness, I built a fresh
59 matches
Mail list logo