[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
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 you
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 your
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 public
I
[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
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
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 to
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 in 5
[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
[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
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.
As I
[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 stated
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 the function
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
[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.
--
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 particularly good
[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:
[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
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 Guido on this
19 matches
Mail list logo
