22C:118 Python Frequently Asked Questions
Our system administrator says you can login, even from home on a Windows machine, to a Linux machine in the department using software at this location (I haven't tried this myself).
Typically, system administrators forget to set up the online help correctly. As a temporary solution, I've copied the online documents for Python version 2.3.1 here, but there are more complete documents at www.python.org.
Possibly, some Python class library has changed since the writing of the book. If you have the patience, you can see for yourself where the differences are (and this is a very instructive process). Let's suppose you want to see what are parameters in the socket class. What you need to do is to track down the source code for the socket class: it will be in file "socket.py" (it's that simple!). The only real challenge is to locate the system library that contains socket.py. Three commands under Unix to do this are:
- locate socket.pyif you're lucky, this will tell you at once where the source code can be found; you can use an editor or the "more" command to then examine the source code. Within the source code, you see the logic, parameters, and even interesting comments about using the socket class. But not all Unix systems have this helpful locate command.
- find / -name socket.py -printthis may generate hundreds of permission errors, but maybe you'll see the location of the socket.py file somewhere amongst the errors.
- which pythonthis command reports the location of the binary executable for Python; for example, it could be /usr/bin/python or /usr/local/bin/python. The "prefix" for the location is /usr or /usr/local. Now, using the same prefix, we guess the following:ls -d /usr/lib/pyth*Provided that the prefix guess was correct, this will list the library containing all the Python library sources. Suppose the response is /usr/lib/python2.3/ then we should find socket.py in that directory.
One way to do this is to put a parameter in the thread constructor. Suppose hiway is the class defining your threads. Its definition might start:class hiway(threading.Thread):To add a parameter to the thread constructor, we need to have an __init__ method within the hiway class definition. For example:def __init__(self,param): self.threadParameter = param threading.Thread.__init__(self)When a statement such ast = hiway((5,"intersect"))is invoked, it will create a new thread with the tuple (5,'intersect') as a parameter, which will be remembered as the self.threadParameter attribute. Now, in the run(self) method, you can refer to self.threadParameter and access those parameters for the particular thread you created earlier. That way, you can customize behavior for each thread.
I usually try Control-C or Control-D to stop the program. But I sometimes find (especially when the program is using the threading module, that these keyboard interrupts aren't effective. In those cases, I open another console window and do the commandps -u hermanwhich lists all the processes I am running (change "herman" to your own userid, of course). Then under the column PID (process id) I find one of them that is running the command "python". That's the process I want to kill; suppose the number is 16782. Then I execute the command (still in the new window)kill -9 16782The "-9" is the highest priority form of kill (the others are maybe set for stun only) and it does the job.
On many Unix systems, there is also a "killall" command. Instead of finding the specific process id of the program you wish to kill, the commandkillall pythonkills all the running python programs you have started, including the one that is resisting keyboard interruptions.
The help() function seems to work, but it is somewhat clumsy. I found that you can directly access the html online documents by opening the following URL in the browser, at least on the departmental linux machines:file:///usr/share/doc/python-docs-2.2.4/html/index.htmlBut even if that doesn't work for you, the equivalent documents are somewhere on python.org.
The first sock.connect() call works OK, but the second one has an error.sock.connect(("www.google.com", 80)) sock.close() url = "www.google.com" sock.connect((url, 80))
The sock object apparently cannot be so easily reused. To fix this, put the linejust before the second sock.connect() call. This line recreates a brand new, clean and never-used socket object for you. Then the code will work just fine.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
Great question! The content length is the number of bytes that follows all the headers (including, I think, the empty last line). Browsers use this to know exactly how many bytes to read without getting "stuck" in a recv() operation. This can be crucial to correct browser operation, especially when a server does not close a connection (ie, does not do sock.close() at the end). Why wouldn't a server close a connection? If the browser sends a "Connection: keep-alive" as part of the headers, that is a hint to the server that it should not close the TCP connection in case the browser will be sending another request very soon -- such as a GET request for a .jpg or .gif image -- which saves having to do extra connection setup overhead between the browser and server.
In my experience, it can be as little as just theI'm guessing this is enough, provided your server immediately closes the connection after sending the web page. But if you ever write a fancy server that can do the keep-alive trick, you would also need to have theHTTP/1.0 200 OK Content-Type: text/htmlkeyword in the headers. And remember, don't forget that empty line between the headers and the actual web page!Content-length: nnnn