Guido van Rossum wrote:
> It's unlikely to be granted. ... The Python call just wraps the
> system call which has a similar API.
What about letting it accept both?
Maintaining strict consistency with the C API here
at the cost of causing pain on almost all uses of
the function seems to be a cas
Georg Brandl wrote:
> There are others who can judge the new API and implementation better than
> me, but I can review the formal issues as soon as the API is accepted.
The API is accepted now, I proposed it and Guido say ok 24hs ago, ;)
I'll update the patch to that API, and let you know throug
[Alan]
>> - Explicitly check that the address passed is a tuple of (string, integer)
[Facundo]
> In the code, I'll just make "host, port = address", I don't think it
> will be a problem at all. Remember that this function primary use is for
> higher level libraries, and that "address" in socket en
On 3/22/07, Alan Kennedy <[EMAIL PROTECTED]> wrote:
> [Alan]
> >> - Explicitly check that the address passed is a tuple of (string, integer)
>
> [Facundo]
> > In the code, I'll just make "host, port = address", I don't think it
> > will be a problem at all. Remember that this function primary use i
Facundo Batista schrieb:
> I updated the patch #1676823, reflecting discussion here:
>
> - The function name changed, now it's _create_connection(). Its
> signature also changed: now, timeout is mandatorily named.
>
> - HTTPConnection has the posibility to call timeout with a number, and
> also
I updated the patch #1676823, reflecting discussion here:
- The function name changed, now it's _create_connection(). Its
signature also changed: now, timeout is mandatorily named.
- HTTPConnection has the posibility to call timeout with a number, and
also with None. In both cases, it updates so
Alan Kennedy wrote:
> def connect(address, **kwargs):
> [snip]
> if kwargs.has_key('timeout'):
> sock.settimeout(kwargs['timeout'])
> [snip]
A problem with interfaces like this is that it makes
it awkward to pass on a value that you received from
higher up.
An
Alan Kennedy wrote:
> - Explicitly check that the address passed is a tuple of (string, integer)
It's more probable that a use pass a list of two values, that a host of
two letters as you suggested above...
> - To raise an exception explaining the parameter expectation when it is not
> met
Alan Kennedy wrote:
> So is that address = host, port = 80?
>
> Or is it address = (host, port), timeout=80?
The latter, as is in the rest of Python...
See your point, you say it's less error prone to make timeout mandatory.
I really don't care, so I'll take your advice...
--
. Facundo
.
Bl
[Josiah]
> Error-wise, I agree that it would be better to pass timeout explicitly
> with a keyword, but generally users will notice their mistake if they
> try to do create_connection(host, port) by ValueError("tuple expected as
> first argument, got str instead") Is it better than
> TypeError("cre
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Alan Kennedy wrote:
> > The standard mechanism in C for doing a non-blocking connect is to
> > issue the connect call, and check the return value for a non-zero
> > error code. If this error code is errno.EAGAIN (code 10035), then the
> > call succeeded, but
"Alan Kennedy" <[EMAIL PROTECTED]> wrote:
>
> [Facundo]
> > Letting "timeout" be positional or named, it's just less error prone.
> > So, if I can make it this way, it's what I prefer, :)
>
> So, if I want a timeout of, say, 80 seconds, I issue a call like this
>
> new_socket = socket.create_co
Alan Kennedy wrote:
> The standard mechanism in C for doing a non-blocking connect is to
> issue the connect call, and check the return value for a non-zero
> error code. If this error code is errno.EAGAIN (code 10035), then the
> call succeeded, but you should check back later for completion of t
[Facundo]
> Letting "timeout" be positional or named, it's just less error prone.
> So, if I can make it this way, it's what I prefer, :)
So, if I want a timeout of, say, 80 seconds, I issue a call like this
new_socket = socket.create_connection(address, 80)
So is that address = host, port = 80?
[Josiah]
> But now the result could be either an error code OR a socket. One of
> the reasons to provide a timeout for the create_connection call, if I
> understand correctly, is to handle cases for which you don't get a
> response back in sufficient time.
AFAICT, that's the only reason. It's not
"Alan Kennedy" <[EMAIL PROTECTED]> wrote:
[snip]
> def create_connection(address, timeout=sentinel):
> [snip]
> if timeout != sentinel:
>new_socket.settimeout(timeout)
> if new_socket.gettimeout() == 0:
>result = new_socket.connect_ex(address)
> else:
>new_
[Facundo]
> So, I have two modifications to make to the patch:
>
> - change the name to "create_connection"
> - make timeout obligatory named
I was going to suggest a third change: for orthogonality with the API
for socket objects, add a blocking parameter as well, i.e.
def create_connection(addr
Josiah Carlson wrote:
> restrict what the user could pass as a value to timeout. It requires
> that you pass timeout explicitly, but that's a (relatively
> inconsequential) API decision.
This is exactly the point. It's an API decision, that you must
communicate to the user, he/she must read it a
Facundo Batista <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > sentinel = object()
> >
> > def connect(HOST, PORT, timeout=sentinel):
> > ...
> > if timeout is not sentinel:
> > sock.settimeout(timeout)
> > ...
> >
> > A keyword argument via **kwargs is also fine. I ha
Josiah Carlson wrote:
> sentinel = object()
>
> def connect(HOST, PORT, timeout=sentinel):
> ...
> if timeout is not sentinel:
> sock.settimeout(timeout)
> ...
>
> A keyword argument via **kwargs is also fine. I have no preference.
I do. The way you showed here, I'm not restr
Steven Bethard wrote:
> is supposed to be a timeout. The modified version::
>
> newsock = socket.create_connection(HOST, PORT, timeout=None)
Warning. The correct function signature is
create_connection(address[, timeout=None])
where address is a tuple (HOST, PORT).
BTW, how can I indic
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> > So, I have two modifications to make to the patch:
> >
> > - change the name to "create_connection"
> > - make timeout obligatory named
> >
> > Is everybody ok with this?
>
> FWLIW, +1. It wa
On 3/20/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> So, I have two modifications to make to the patch:
>
> - change the name to "create_connection"
> - make timeout obligatory named
>
> Is everybody ok with this?
FWLIW, +1. It was not immediately apparent to me that the third argument in::
Alan Kennedy wrote:
> [Facundo]
>> But, I recognize that maybe it's [connect] not the best name. What about
>> "create_connection"?
>
> I have no strong feelings about it, other than to say it should not be
> "connect". How about
Ok. "create_connection", then.
> Ah, but it's too late by the tim
[Facundo]
> But, I recognize that maybe it's [connect] not the best name. What about
> "create_connection"?
I have no strong feelings about it, other than to say it should not be
"connect". How about
* connect_to_server()
* open_connection()
* open_client_connection()
There's no need to inclu
Alan Kennedy wrote:
> Sorry, my mistake.
No problem.
> So, a question I would ask is: Is "connect" the right name for that function?
> ...
> Perhaps a better name might be "create_connected_client_socket", or
> something equally descriptive?
Guido proposed "connect_with_timeout". I don't like
[Alan Kennedy]
>> I see that your updated socket.connect() method takes a timeout
>> parameter, which defaults to None if not present, e.g.
[Facundo Batista]
> I did NOT update a connect() method. I created a connect() function, in
> the module socket.py (there's also a connect() method in the soc
Alan Kennedy wrote:
> I see that your updated socket.connect() method takes a timeout
> parameter, which defaults to None if not present, e.g.
I did NOT update a connect() method. I created a connect() function, in
the module socket.py (there's also a connect() method in the socket
object, but I
[Facundo Batista]
> Do you have any news about this?
Re: Patch 1676823
http://sourceforge.net/tracker/index.php?func=detail&aid=1676823&group_id=5470&atid=305470
Since I've just written a lot of socket stuff for jython, I thought
I'd have a look at the patch.
I like the idea of adding better soc
On March 15, Georg Brandl wrote:
> I'll review it tomorrow.
Do you have any news about this?
Regards,
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http:/
I'll review it tomorrow.
Georg
Guido van Rossum schrieb:
> I need to shed load; I've asked Georg to review this. If he's fine
> with it, Facundo can check it in.
>
> On 3/15/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>> Facundo Batista wrote:
>>
>> > I studied Skip patch, and I think he is i
I need to shed load; I've asked Georg to review this. If he's fine
with it, Facundo can check it in.
On 3/15/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Facundo Batista wrote:
>
> > I studied Skip patch, and I think he is in good direction: add a
> > NetworkConnection object to socket.py, and
Facundo Batista wrote:
> I studied Skip patch, and I think he is in good direction: add a
> NetworkConnection object to socket.py, and then use it from the other
> modules.
As of discussion in the patch tracker, this class is now a function in
socket.py.
This function connect() does the connect
I studied Skip patch, and I think he is in good direction: add a
NetworkConnection object to socket.py, and then use it from the other
modules.
This NetworkConnection basically does what all the other modules do
once and again, so no mistery about it (basically calls getaddrinfo
over the receive
34 matches
Mail list logo
