Message175877
| Author |
lcatucci |
| Recipients |
barry, giampaolo.rodola, janssen, jcea, lcatucci, pitrou, r.david.murray |
| Date |
2012年11月18日.15:14:51 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1353251691.41.0.780064061602.issue4473@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Updated 02 and 03 patches (mostly) in line with Antoine's review comments:
> 2) poplib_02_server_capabilities_v3.diff:
> - please try to follow PEP 8 (i.e. `capa = {}` not `capa={}`)
> - I think the capa() result should be a dict mapping str keys to str > values (not bytes), since that part of the POP3 protocol seems to
> have a well-defined character set (ASCII)
Completely right. Done.
> 3) poplib_03_starttls_v3.diff:
>
> - same comment about PEP 8
where?
> - why did you change the signature of the _create_socket()
> method? it looks gratuitous
undone
> - the new method should be called starttls() as in other modules, not > stls()
Here I'm following: at :ref:`pop3-objects` in Doc/library/poplib.rst,
All POP3 commands are represented by methods of the same name, in
lower-case; most return the response text sent by the server.
IMHO, having a single method with a name different than the underlying
POP command would just be confusing. For this reason, I'd rather avoid
adding an alias like in
starttls = stls
or the reverse...
> - starttls() should only take a context argument; no need to support > separate keyfile and certfile arguments
Right, non need to mimick pre-SSLContext method signatures!
> - what is the point of catching errors like this:
> [...]
undone |
|