ProNdubuisi:
Hello world, does anyone here write sever side code with python? just learnt the language and want to go into web dev with it, but all i see is Django tutorials online, i dislike frame works. Do you know how i can hard code Python like you hard code php, html css and the rest? i need someone who has done it before to walk me through

[b]Do I have to use a web framework?
[/b]Whether or not you use a web framework in your project depends on your experience with web development and what you're trying to accomplish. If you are a beginner programmer and just want to work on a web application as a learning project then a framework can help you understand the concepts listed above, such as URL routing, data manipulation and authentication that are common to the majority of web applications.

On the other hand if you're an experienced programmer with significant web development experience you may feel like the existing frameworks do not match your project's requirements. In that case, you can mix and match open source libraries such as Werkzeug for WSGI plumbing with your own code to create your own framework. There's still plenty of room in the Python ecosystem for new frameworks to satisfy the needs of web developers that are unmet by Django, Flask, Pyramid, Bottle and many others.

In short, whether or not you need to use a web framework to build a web application depends on your experience and what you're trying to accomplish. Using a web framework to build a web application certainly isn't required, but it'll make most developers' lives easier in many cases.

Dreadlord:
In my opinion, I am I don't see why you want to reinvent the wheel. I bet you don't use class libraries, you don't even use a programming language. You code in Binary. You don't even need code, you process data manually since you are a boss man.

4kings:

Haba this is too far.
He just wants to know how to do it himself.
Me too.. That knowledge could be useful.

Dreadlord:

My bad, I I just get really frustrated when someone thinks it's way cooler to write a hello world application in treefrog than writing a complex web application in Ruby or php.
OP, my apologies. I you should try oriely's programming Python 4th edition it has what you are looking for. Once again sorry.

Dreadlord:
In my opinion, I am I don't see why you want to reinvent the wheel. I bet you don't use class libraries, you don't even use a programming language. You code in Binary. You don't even need code, you process data manually since you are a boss man.

Dreadlord:

My bad, I I just get really frustrated when someone thinks it's way cooler to write a hello world application in treefrog than writing a complex web application in Ruby or php.
OP, my apologies. I you should try oriely's programming Python 4th edition it has what you are looking for. Once again sorry.

It is a specification for simple and universal interface between web servers and web applications or frameworks for the Python programming language.

The document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers.

Python currently boasts a wide variety of web application frameworks, such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web -- to name just a few [1] . This wide variety of choices can be a problem for new Python users, because generally speaking, their choice of web framework will limit their choice of usable web servers, and vice versa.

By contrast, although Java has just as many web application frameworks available, Java's "servlet" API makes it possible for applications written with any Java web application framework to run in any web server that supports the servlet API.

The availability and widespread use of such an API in web servers for Python -- whether those servers are written in Python (e.g. Medusa), embed Python (e.g. mod_python), or invoke Python via a gateway protocol (e.g. CGI, FastCGI, etc.) -- would separate choice of framework from choice of web server, freeing users to choose a pairing that suits them, while freeing framework and server developers to focus on their preferred area of specialization.

This PEP, therefore, proposes a simple and universal interface between web servers and web applications or frameworks: the Python Web Server Gateway Interface (WSGI).

lordZOUGA:
If you are interested in returning HTML from a server just like most webservers, then you can just create a server listening to a port and return a bunch of strings from the server (sounds easy right?).

The problem is that you also have to build HTTP headers and manage I/O between server and clients (this is unbelievably complex).

Frameworks are helpful because they have already implemented most of these features reliably.

I encourage you to try building a webserver from scratch, it will make you appreciate the usefulness of Frameworks.

REQUEST_METHOD
The HTTP request method, such as "GET" or "POST" . This cannot ever be an empty string, and so is always required.
SCRIPT_NAME
The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server.
PATH_INFO
The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.
QUERY_STRING
The portion of the request URL that follows the "?" , if any. May be empty or absent.
CONTENT_TYPE
The contents of any Content-Type fields in the HTTP request. May be empty or absent.
CONTENT_LENGTH
The contents of any Content-Length fields in the HTTP request. May be empty or absent.
SERVER_NAME , SERVER_PORT
When combined with SCRIPT_NAME and PATH_INFO , these two strings can be used to complete the URL. Note, however, that HTTP_HOST , if present, should be used in preference to SERVER_NAME for reconstructing the request URL. See the URL Reconstruction section below for more detail. SERVER_NAME and SERVER_PORT can never be empty strings, and so are always required.
SERVER_PROTOCOL
The version of the protocol the client used to send the request. Typically this will be something like "HTTP/1.0" or "HTTP/1.1" and may be used by the application to determine how to treat any HTTP request headers. (This variable should probably be called REQUEST_PROTOCOL , since it denotes the protocol used in the request, and is not necessarily the protocol that will be used in the server's response. However, for compatibility with CGI we have to keep the existing name.)
HTTP_ Variables
Variables corresponding to the client-supplied HTTP request headers (i.e., variables whose names begin with "HTTP_" ). The presence or absence of these variables should correspond with the presence or absence of the appropriate HTTP header in the request.