Guido van Rossum wrote:
> > > Is it time for a sockettools module, maybe?
> >
> > +1!
>
> -1. The new module would be just as much a jumble of unrelated APIs as
> the socket module already is, so there's no particularly good reason
> to create an arbitrary separation. Also, KISS.
I agree with Gui
[Facundo]
> Talk is cheap.
I'm sorry if you see my attempts to review your patch as "cheap talk".
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and asyn
[Greg Ewing]
> or
>
> d) Put it in another module
>
> Is it time for a sockettools module, maybe?
+1!
Alan.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
On 3/21/07, Alan Kennedy <[EMAIL PROTECTED]> wrote:
> [Greg Ewing]
> > or
> >
> > d) Put it in another module
> >
> > Is it time for a sockettools module, maybe?
>
> +1!
-1. The new module would be just as much a jumble of unrelated APIs as
the socket module already is, so there's no particul
[EMAIL PROTECTED] wrote:
> Facundo> c) Write the function in socket.py, non public
Also this option has the problem that it would be
a strange usage of "non-public", since the function
would be designed for use by other modules and not
used at all in the module it's supposedly private
to.
Facundo Batista wrote:
> So, as a resume of the choices we still need to settle:
>
> a) Repeat the same functionality in 5 other libraries
> b) Write the function in socket.py, public
> c) Write the function in socket.py, non public
or
d) Put it in another module
Is it time for a so
On 3/21/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> > So, as a resume of the choices we still need to settle:
> >
> > a) Repeat the same functionality in 5 other libraries
> > b) Write the function in socket.py, public
> > c) Write
[Josiah]
> In regards to 'there is no way to
> create a blocking socket this way', Alan is off his rocker.
I am not off my rocker.
And I never wrote the words you place in quotes (except in relation to
an earlier defect in the patch where the timeout=None value was
ignored).
What I clearly state
Facundo Batista <[EMAIL PROTECTED]> wrote:
> Alan Kennedy wrote:
> > I recommend modifying the patch to remove *all* proposed changes to
> > the socket module. Instead, the patch should restrict itself to fixing
> > the httplib module.
>
> -1 to repeat the same functionality in 5 other libraries.
[Facundo]
> Talk is cheap.
I'm sorry if you see my attempts to review your patch as "cheap talk".
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and asyn
[Facundo]
> Talk is cheap.
I'm sorry if you see my attempts to review your patch as "cheap talk".
Maybe I should have just kept my opinion to myself.
You'll get your chance to return the favour when I check in my
upcoming 1000+ line change to jython 2.3 to bring the jython socket,
select and asyn
On 3/21/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> So, as a resume of the choices we still need to settle:
>
> a) Repeat the same functionality in 5 other libraries
> b) Write the function in socket.py, public
> c) Write the function in socket.py, non public
The fact that it's needed i
Alan Kennedy wrote:
> So what are we voting on exactly? The patch as it currently is? The
> patch has not been updated to reflect recent discussions on the list.
> Will the patch be updated before the vote?
The voting is on a, b or c.
The patch will be updated after I know what python-dev want t
Alan Kennedy wrote:
> I think this patch is poorly designed and poorly implemented. There
> are multiple problems in its 17 lines of socket module code; every
> time I look I find a new problem.
Code which is copied verbatim from httplib, and also occurs with slight
variations in several other st
[Facundo]
> Voting is open, ;)
So what are we voting on exactly? The patch as it currently is? The
patch has not been updated to reflect recent discussions on the list.
Will the patch be updated before the vote?
I have one more issue with the patch.
I think that the exception handling in the fun
Facundo> Voting is open, ;)
...
Facundo> So, as a resume of the choices we still need to settle:
Facundo> a) Repeat the same functionality in 5 other libraries
Facundo> b) Write the function in socket.py, public
Facundo> c) Write the function in socket.py, non publi
Alan Kennedy wrote:
> But remember that by adding a new function to the socket module to
> support httplib et al, you are also adding a function to the socket
> module that will be used directly by end users.
>
> I vote to reject this patch.
Well, you can vote to name it _create_connection(), if
Alan Kennedy wrote:
> The proposed new function does not belong in the socket module. In
> contrast to all of the other socket creation and management
> functionality in the socket module, the new function does not handle
> non-blocking IO.
The rest of the socket module isn't going anywhere. If yo
[Facundo Batista]
> Remember that this function primary use is for
> higher level libraries
Yes, I see that clearly now.
But remember that by adding a new function to the socket module to
support httplib et al, you are also adding a function to the socket
module that will be used directly by end
19 matches
Mail list logo
