<div dir="ltr"><div><div><div>An argument against this API, is that any caller of recv should be doing error handling (i.e.: catching exceptions from the socket).<br><br></div>Changing into an iterator makes it less likely that error handling will be properly coded, and makes the error handling more obscure.<br><br></div>Thus although the API would make the code more readable for the [wrong case] of not handling errors; the real issue is that it would make the code more obscure for the proper case of error handling.<br></div><div><br></div><div>We should focus on the proper use case: using recv with error handling & thus not add this API.<br></div></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top:1px solid #d3d4de">
<tr>
<td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td>
<td style="width:470px;padding-top:12px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link" target="_blank" style="color:#4453ea">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 8, 2018 at 10:05 PM, Oscar Smith <span dir="ltr"><<a href="mailto:oscardssmith@gmail.com" target="_blank">oscardssmith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The arguments for including this API is that it allows easy iteration over the results of a connection allowing it to be used with any of the features of itertools or any other library accepting iterables. recv is only used in places where the iterable protocol could be used, so it makes sense for consistency to use the API shared by the rest of Python. <br></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_-6878450984810136432gmail_signature" data-smartmail="gmail_signature"><font style="color:rgb(204,0,0);background-color:rgb(255,102,102)" size="2"><span style="font-family:arial,helvetica,sans-serif"><span><span style="background-color:rgb(255,255,255)"></span></span><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">Oscar Smith</span><span><span style="background-color:rgb(255,255,255)"></span></span></span></font></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Mon, Jan 8, 2018 at 7:25 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Jan 08, 2018 at 10:17:30AM -0600, Oscar Smith wrote:<br>
> I am currently working on a program where it would be really useful if a<br>
> connection had a __next__ method, because then it would be much easier to<br>
> iterate over.<br>
<br>
</span>What sort of connection are you referring to?<br>
<span><br>
<br>
> It would just be an alias to recv, but would allow you to do<br>
> things like merging the results of connections using heapq.merge that<br>
> currently are highly non-trivial to accomplish.<br>
<br>
</span>This gives you an iterator which repeatedly calls connection.recv until<br>
it raises a FooException, then ends.<br>
<br>
def conn_iter(connection):<br>
<span> try:<br>
while True:<br>
yield connection.recv()<br>
</span> except FooException: # FIXME -- what does recv actually raise?<br>
return<br>
<br>
Doesn't seem "highly non-trivial" to me. Have I missed something?<br>
<span><br>
<br>
> Is there a reason this API isn't supported?<br>
<br>
</span>You are asking the wrong question. Adding APIs isn't "default allow",<br>
where there has to be a reason to *not* support it otherwise it gets<br>
added. It is "default deny" -- there has to be a good reason to add it,<br>
otherwise it gets left out. YAGNI is an excellent design principle, as<br>
it is easier to add a useful API later, than to remove an unnecessary or<br>
poorly designed one.<br>
<br>
So the question needs to be:<br>
<br>
"Is this a good enough reason to support this API?"<br>
<br>
Maybe, maybe not. Not every trivial wrapper function needs to be a<br>
method.<br>
<br>
But perhaps this is an exception: perhaps iterability is such a common<br>
and useful API for connections that it should be added, for the same<br>
reason that files are iterable.<br>
<br>
Care to elaborate on why this would be useful and why the generator I<br>
showed above isn't satisfactory?<br>
<span class="m_-6878450984810136432HOEnZb"><font color="#888888"><br>
--<br>
Steve<br>
</font></span><div class="m_-6878450984810136432HOEnZb"><div class="m_-6878450984810136432h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div>