Re: [Python-Dev] The socket HOWTO
Hello, On Sun, 29 May 2011 17:20:29 +0200 "Martin v. Löwis" wrote: > > I would like to suggest that we remove the socket HOWTO (currently at > > http://docs.python.org/dev/howto/sockets.html) > > -1. I think there should be a Python-oriented introduction to sockets. > You may have complaints about the specific wording of the text, but > please understand that these are probably irrelevant to most > first-time readers of this text. My observation is that people actually > don't read the text that much, but instead try to imitate the examples. So what you're saying is that the text is mostly useless (or at least quite dispensable), but you think it's fine that people waste their time trying to read it? Some of the people reading our docs are not fluent English readers, and it can be quite an effort for them to read some big chunk of text which will be ultimately pointless. > So if the examples are good (and I think they are, mostly), it's of > minor relevance whether the text makes all sense the first time. I'm not sure why the examples are good (for example, modern client code should probably use create_connection() with a host name, not connect()). Also, really, to socket beginners, I think the primary advice should be: first try to find some high-level library that does the dirty work for you (for example some protocol-specific lib on the client side, or something like Twisted or asyncore on the server side). Not "hey, here's how you write a threaded server in 4 lines of code, and wow, look, you can also write non-blocking code using select() too!". > It's not important > to first-time readers to actually understand that, and the wording > explicitly tells them that they don't need to understand. It says > "there is more stuff, and you won't need it, and the stuff you need > is called INET and STREAM". Well... in a couple of months, someone will tell them their code doesn't support IPv6 and they'll be lost. > > what's "select"?) > > It's well explained in the section Non-blocking Sockets, isn't it? I don't think it explains well how a non-blocking socket works. It's very opinionated and has little useful technical content. EAGAIN and EWOULDBLOCK are not even mentioned! > It's a HOWTO - of course it has advise without justification. Well, I think that's bad. When we give advice to users, we should explain the motivation of the advice given. Otherwise we convey the impression that there's some magic that people shouldn't try to understand. > > what is a "nasty death" and how is that supposed to > > happen? couldn't the author have put a 3-line example to demonstrate > > this supposed drawback and how it manifests?). > > It may well be that the author didn't fully understand the problem > when writing the text, so I wouldn't mind removing this specific > paragraph. +1. When reading it I get the idea that the OS might kill sockets in my back, while in reality the only way a EBADF can happen is if I explicitly close the socket - i.e. a programming error on my part. > I'd drop the entire "Performance" section - there is much more > to be said about socket performance than a few paragraphs of text, > and for the target audience, performance is probably no concern. +1 :) Thank you Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
Antoine Pitrou: > So what you're saying is that the text is mostly useless (or at least > quite dispensable), but you think it's fine that people waste their > time trying to read it? I found it useful when starting to write socket code. Later on I learnt more but, as an introduction, this document was great. It is written in an approachable manner and doesn't spend time on details unimportant to initial understanding. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] keyword-only arguments and varags
Currently, def f(*, kw, **kwargs): pass is valid syntax, but def f(*args, *, kw): pass is not. I don't see any mention of it in the PEP but perhaps there is a good reason this isn't allowed. It seems to be perfectly well-defined to me. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] keyword-only arguments and varags
On Sun, Jun 5, 2011 at 11:45 AM, Benjamin Peterson wrote: > Currently, > > def f(*, kw, **kwargs): pass > > is valid syntax, but > > def f(*args, *, kw): pass > > is not. > > I don't see any mention of it in the PEP but perhaps there is a good > reason this isn't allowed. It seems to be perfectly well-defined to > me. Really? There's two single-stars there. One says "accept arbitrary positional arguments and place them in a tuple named args", the second says "don't accept any more positional args". You can't have it both ways, so the compiler complains. The following works fine to mix keyword-only arguments with arbitrary positional arguments, so I don't see a problem: def f(*args, kw): pass Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The socket HOWTO
>> -1. I think there should be a Python-oriented introduction to sockets. >> You may have complaints about the specific wording of the text, but >> please understand that these are probably irrelevant to most >> first-time readers of this text. My observation is that people actually >> don't read the text that much, but instead try to imitate the examples. > > So what you're saying is that the text is mostly useless (or at least > quite dispensable), but you think it's fine that people waste their > time trying to read it? No, that's not what I said. I said the people actually *don't* read the text, so they won't waste time with it. They only glance at the text, enough to understand the examples. > Some of the people reading our docs are not fluent English readers, and > it can be quite an effort for them to read some big chunk of text which > will be ultimately pointless. You completely misunderstood. I didn't say that the reading the text is pointless. I said that people don't read this text, nor any software documentation, in particular when they are not fluent in English. >> So if the examples are good (and I think they are, mostly), it's of >> minor relevance whether the text makes all sense the first time. > > I'm not sure why the examples are good (for example, modern client > code should probably use create_connection() with a host name, not > connect()). I disagree. create_connection is an advanced function - you shouldn't be using it unless you know what it is doing. As a socket tutorial, people do have to know about connect. > Also, really, to socket beginners, I think the primary advice should > be: first try to find some high-level library that does the dirty work > for you (for example some protocol-specific lib on the client side, or > something like Twisted or asyncore on the server side). No no no no no. Absolutely not. a) telling people who want to learn sockets "don't learn sockets, learn some higher-level library" is besides the point. What do you tell them when they did that, and now come back to learn sockets? b) telling people to use Twisted or asyncore on the server side if they are new to sockets is bad advice. People *first* have to understand sockets, and *then* can use these libraries and frameworks. Those libraries aren't made to be black boxes that work even if you don't know how - you *have* to know how they work inside, or else you can't productively use them. > Not "hey, > here's how you write a threaded server in 4 lines of code, and wow, > look, you can also write non-blocking code using select() too!". I'd happily kill the entire non-blocking discussion from the tutorial if it hurts you as much as it hurts me. I wish this non-blocking stuff never went into Python. > Well... in a couple of months, someone will tell them their code doesn't > support IPv6 and they'll be lost. No. In a couple of months, they'll understand sockets much better, so they'll be able to support IPv6 easily. >> It's a HOWTO - of course it has advise without justification. > > Well, I think that's bad. When we give advice to users, we should > explain the motivation of the advice given. Otherwise we convey the > impression that there's some magic that people shouldn't try to > understand. It's not that bad. Please reconsider. People do get a lot of advise in their lives that isn't motivated down to the root cause, and accept advise from authority. Only if they understand what it does, they ask why. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
