On Tue, Feb 15, 2011 at 5:54 PM, Paul Moore wrote:
> The PEP should address what will happen with the dependency on
> zope.interface. Getting interfaces into the stdlib has *also* been
> discussed often in the past, and has never happened. It might even be
> contentious enough to warrant a second
On 15 February 2011 00:45, wrote:
> As far as the difficulties of "finding" the good ideas in Twisted goes,
> there are several people familiar with Twisted already contributing to this
> thread. Between us all, I'm sure we can dig out the insidiously buried
> secrets. As I mentioned before, I'
On Tue, Feb 15, 2011 at 11:09 AM, Daniel Stutzbach wrote:
> If we go with something based on or inspired by Twisted, that solves some
> problems, but creates others. Will users be able to later migrate to using
> Twisted proper? Will the standard library module and Twisted go out of
> sync? Wha
On Tue, Feb 15, 2011 at 10:45 AM, wrote:
> As far as the difficulties of "finding" the good ideas in Twisted goes,
> there are several people familiar with Twisted already contributing to this
> thread. Between us all, I'm sure we can dig out the insidiously buried
> secrets. As I mentioned bef
On Sat, Feb 12, 2011 at 8:20 PM, wrote:
> What part do you think is a hard problem? Convincing people to switch to a
> new API?
>
I think the hard parts is coming up with an API that's simple enough to
learn quickly but powerful enough for to cover most use-cases and cleanly
extendable to cover
On 2/14/2011 5:15 PM, Greg Ewing wrote:
Giampaolo Rodolà wrote:
for me it should also fit one crucial requirement: it
should be *simple* and reflect the simplicity and "taste" of all other
stdlib modules, and to fulfill such a requirement I think Twisted
probably needs to be "adapted" a bit.
On 14 Feb, 10:15 pm, greg.ew...@canterbury.ac.nz wrote:
Giampaolo Rodol� wrote:
for me it should also fit one crucial requirement: it
should be *simple* and reflect the simplicity and "taste" of all other
stdlib modules, and to fulfill such a requirement I think Twisted
probably needs to be "ada
Giampaolo Rodolà wrote:
for me it should also fit one crucial requirement: it
should be *simple* and reflect the simplicity and "taste" of all other
stdlib modules, and to fulfill such a requirement I think Twisted
probably needs to be "adapted" a bit.
My thoughts exactly -- from a bird's eye
Giampaolo Rodolà wrote:
> Although I don't use it, it seems that Twisted managed to do this by
> splitting the concepts of "transport" and "protocol" / "application"
> and by using zope.interface.
You might want to look at the ILU core, too, just for ideas. Somewhat
to my surprise, the link htt
2011/2/13 Antoine Pitrou :
>
>> It would then be subject to python-dev development policy rather than
>> twisted dev policy (which is even stricter!). Would the twisted devs
>> *really* want that? We could use the same processes we have for
>> "externally maintained" libraries, but they have withou
On 2/13/2011 5:23 PM, Nick Coghlan wrote:
On Mon, Feb 14, 2011 at 8:11 AM, wrote:
Excluding stuff is not hard, seriously. It's not hard to see that wxPython
integration doesn't belong in the stdlib. There are more useful aspects of
the task to discuss.
I think part of the problem is that t
On Mon, Feb 14, 2011 at 8:36 AM, Michael Foord
wrote:
> Well, what about it? The virtue of twisted is that even if we haven't all
> used it, we've all heard of it. That speaks volumes about its penetration
> into the python world.
Just a mere suggestion. The fact that this discussion exists means
On 13/02/2011 22:24, James Mills wrote:
On Mon, Feb 14, 2011 at 8:11 AM, wrote:
On 08:06 pm, greg.ew...@canterbury.ac.nz wrote:
exar...@twistedmatrix.com wrote:
On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
I was thinking of something
On Mon, Feb 14, 2011 at 8:11 AM, wrote:
> On 08:06 pm, greg.ew...@canterbury.ac.nz wrote:
>>
>> exar...@twistedmatrix.com wrote:
>>>
>>> On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
>
> On Sun, 13 Feb 2011 11:19:06 +1300
> Greg Ewing wrote:
I was thinking of something li
On Mon, Feb 14, 2011 at 8:11 AM, wrote:
>
> Excluding stuff is not hard, seriously. It's not hard to see that wxPython
> integration doesn't belong in the stdlib. There are more useful aspects of
> the task to discuss.
I think part of the problem is that those of us that aren't Twisted
users a
On 08:06 pm, greg.ew...@canterbury.ac.nz wrote:
exar...@twistedmatrix.com wrote:
On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
I was thinking of something lighter-weight than that.
Twisted Core
I just had a look at the docs for Twist
exar...@twistedmatrix.com wrote:
On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
I was thinking of something lighter-weight than that.
Twisted Core
I just had a look at the docs for Twisted Core, and it lists
10 sub-modules. The only on
> It would then be subject to python-dev development policy rather than
> twisted dev policy (which is even stricter!). Would the twisted devs
> *really* want that? We could use the same processes we have for
> "externally maintained" libraries, but they have without fail caused us
> problems.
On 13/02/2011 14:23, Antoine Pitrou wrote:
On Sun, 13 Feb 2011 19:18:52 +1000
Nick Coghlan wrote:
If there is an essential subset of the API that the Twisted devs think
would be a suitable replacement for asyncore, while providing a more
straightforward migration path into Twisted itself, then
On Sun, 13 Feb 2011 19:18:52 +1000
Nick Coghlan wrote:
>
> If there is an essential subset of the API that the Twisted devs think
> would be a suitable replacement for asyncore, while providing a more
> straightforward migration path into Twisted itself, then it certainly
> makes sense to include
On Sun, Feb 13, 2011 at 2:20 PM, wrote:
>> The desire is there, but it's a hard problem. There was a similar
>> discussion before PyCon 2009, but not much came of it:
>>
>> http://mail.python.org/pipermail/python-dev/2009-March/086678.html
>
> I started working on a PEP last year, but I didn't g
> I started working on a PEP last year, but I didn't get very far partly
> because I doubted the desire.
>
> What part do you think is a hard problem? Convincing people to switch to a
> new API? *Defining* the new API doesn't seem very hard to me.
>
I must say that the only time I needed the fun
On 12:34 am, stutzb...@google.com wrote:
On Sat, Feb 12, 2011 at 4:22 PM, wrote:
Do people want to seriously consider deprecating asyncore and adding a
replacement for it to the stdlib?
(Hey, PyCon is coming up. How convenient. :)
The desire is there, but it's a hard problem. There was a
On Sat, Feb 12, 2011 at 4:22 PM, wrote:
> Do people want to seriously consider deprecating asyncore and adding a
> replacement for it to the stdlib?
>
> (Hey, PyCon is coming up. How convenient. :)
>
The desire is there, but it's a hard problem. There was a similar
discussion before PyCon 200
On 12:13 am, p.f.mo...@gmail.com wrote:
On 12 February 2011 23:10, wrote:
On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
Antoine Pitrou wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
So maybe it's time to design a new module with a better API
and deprecate the old one?
On 12 February 2011 23:10, wrote:
> On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
>>
>> Antoine Pitrou wrote:
>>>
>>> On Sun, 13 Feb 2011 11:19:06 +1300
>>> Greg Ewing wrote:
>>
So maybe it's time to design a new module with a better API
and deprecate the old one?
>>>
>>> That's call
On 10:46 pm, greg.ew...@canterbury.ac.nz wrote:
Antoine Pitrou wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
So maybe it's time to design a new module with a better API
and deprecate the old one?
That's called Twisted.
I was thinking of something lighter-weight than that.
Antoine Pitrou wrote:
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
So maybe it's time to design a new module with a better API
and deprecate the old one?
That's called Twisted.
I was thinking of something lighter-weight than that.
--
Greg
Nick Coghlan wrote:
Flawed API + popularity = years of fun*
So maybe it's time to design a new module with a better API
and deprecate the old one?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
On Sun, 13 Feb 2011 11:19:06 +1300
Greg Ewing wrote:
> Nick Coghlan wrote:
>
> > Flawed API + popularity = years of fun*
>
> So maybe it's time to design a new module with a better API
> and deprecate the old one?
That's called Twisted.
___
Python-D
Antoine Pitrou writes:
> Would that be a Mapping or a Sequence?
Sure it would be nowhere near as predictable as a Mapping or Sequence,
so Isuppose it would be a Container ... although the probability of
OverflowException is near 1.
___
Python-Dev maili
On Sat, Feb 12, 2011 at 5:56 AM, Giampaolo Rodolà wrote:
> Yeah, the original API design (which is very inflexible) and the lack
> of maintenance for many years is at the base of asyncore problems.
> I still think it worths some love as a stdlib module, though.
Oh, definitely. It's popularity is
On Fri, Feb 11, 2011 at 10:36 AM, Antoine Pitrou wrote:
> Daniel Stutzbach wrote:
> > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
>
> Would that be a Mapping or a Sequence?
Before or after monkey-patching? :-)
--
Daniel Stutzbach
_
Yeah, the original API design (which is very inflexible) and the lack
of maintenance for many years is at the base of asyncore problems.
I still think it worths some love as a stdlib module, though.
For 3.3 I have in mind to revamp asyncore/asynchat a bit by
introducing SSL support and finally add
2011/2/11 Antoine Pitrou :
> On Fri, 11 Feb 2011 10:11:54 -0800
> Daniel Stutzbach wrote:
>> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote:
>> >
>> > And finally remember that asyncore is the most monkey-patched module
>> > in the world. :-)
>>
>>
>> I propose that in Python 3.3 we rena
On Fri, 11 Feb 2011 10:11:54 -0800
Daniel Stutzbach wrote:
> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote:
> >
> > And finally remember that asyncore is the most monkey-patched module
> > in the world. :-)
>
>
> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
W
On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote:
>
> And finally remember that asyncore is the most monkey-patched module
> in the world. :-)
I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys.
--
Daniel Stutzbach
___
Python
On Fri, Feb 11, 2011 at 6:28 AM, Victor Stinner
wrote:
> Le vendredi 11 février 2011 à 14:52 +0100, Giampaolo Rodolà a écrit :
>> >> New Revision: 88395
>> >>
>> >> Log:
>> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher
>> >> gets closed only once.
>> >> In different
Le vendredi 11 février 2011 à 14:52 +0100, Giampaolo Rodolà a écrit :
> >> New Revision: 88395
> >>
> >> Log:
> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher
> >> gets closed only once.
> >> In different occasions close() might be called more than once, causing
> >>
I'm sorry, I'm going to revert those checkins.
They are very minor changes which I'm sure don't break anything, but I
understand your complain.
--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
2011/2/11 Nick Coghlan :
> On Fri, Feb 11, 2011 at 11:04 PM, giampao
On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola
wrote:
> Author: giampaolo.rodola
> Date: Fri Feb 11 14:04:18 2011
> New Revision: 88395
>
> Log:
> asyncore: introduce a new 'closed' attribute to make sure that dispatcher
> gets closed only once.
> In different occasions close() might be calle
41 matches
Mail list logo
