Hi Dorje and Alan

First off, everything that Alan has said is true and I would like to re-iterate my lack of qualifications. I depend on people like Alan to guide me. Just a couple of days ago I posted an extremely silly question about shell programming.

So having said that I think there are two veins of discussion that would be helpful to you, One a framework discussion and the other a list of terms you need to learn.

I have not used Django for any project but I have read about it and it is very popular, however just because everyone else is using does not mean you have to. Alan and Ken are right, you don't have to know what's under the hood to use a framework but I think the choice of a framework is of paramount importance. It appears to me that Django is an all-in-one monolithic application. Years ago Zope was the number 1 and now it's basically gone. Unless speed and easy of use are of paramount importance I suggest that you look at Pylons/Turbogears(unless of course you want to join me in the search for the lost city of Atlantis(WSGI programing)). This way if you do not like your framework you can take much of your code with you to another framework. I don't think this will be the case with Django.

You can switch out components with relative ease with Pylons and to a lesser degree with Turbogears.

Here are some terms you need to learn. I can help if you need it or you might want to search wikipedia for them:
ORM relational mapper, you might look at SQLAlchemy
MVC Model view Controller
Templating engine
WSGI
Url Routing

I am sure I will think of more later....


Once your done your App, you then have to host it, you have far fewer choices then with PHP. You could try Webfaction or maybe you would like to run it on a virtual server, Slice hosting has pretty cheap packages($25 ish)


Sorry to make this about me again but in my defense of my last post, I really think that you do want to think about long term commitments, it takes along time to learn this stuff. I use GTK and I don't care about the code it's written in. I am confident that it will be with us in five to ten years and I am totally confident that Python will be with us for much longer. I have been thinking about learning TCL/Tk recently. It has lots of benefits but it also looks like it has been in a steady decline for some time. Choosing a language or a framework is in a sense a business decision. I don't think that the Python framework world has stabilized just yet, I am personally confused about what to do, so remember it is the blind leading the blind here but I urge you to consider something that decouples well.

-Patrick



Alan Gauld wrote:
"Patrick" <[EMAIL PROTECTED]> wrote

I am in the small minority of people who are don't like frameworks.

There used to be a small minority of people who didn't like compiled
or other high level languages. But they gradually died out... There
was even a very small community who didn't like assembler, preferring
to enter binary or hexcodes directly, but they died out very quickly!

really struggling to get going without one.

Yep, that's why other folks like them! :-)

You can actually program directly on the WSGI layer. I am trying to do this. You get CGI like control(actually better) with high performance

Just as you can program a Windows GUI using the Win32 API.
Or use XLib on X windows. (X in very interesting because it has
many layers of abstraction designed right in, from XLib to Xt to
XView/Motif/GTK etc) But its all incredibly painful!

According to this article there have been changes to 350K lines of code in Django:
http://www.djangoproject.com/weblog/2008/sep/03/1/

I am sure this is an awesomely powerful framework but how the hell does anyone understand the magic under the cover with so many lines of code?

Only the developers do. There are hundreds of thousands of lines in a
GUI framework too but nobody feels the need to read them all before
using wxWindows or Tcl/Tk or GTK...

Are you really programming in Python or are you programming in Django now?

You are programming in Python using Django.
Similarly when you import the os module you are programming in Python
using the os module. If you look at the source for os and then drill down
to look at the Unix C libraries utilised you will find many thousands of
lines of code there too, before you ultimately call the OS system calls.
If you then drill into the system call code (which you can do in Linux or
Darwin) you will find that they eventually call BIOS routines written in
assembler. But very few programmers bother reading the assembler
code for the BIOS routine (interrupt 0x13 from memory?) that writes to
disk before considering whether they should use file.writelines() in
Python...

The whole of software engineering is built up on layers of software
provided by others. 'Framework' is just a fancy name for a particular
type of layer. If it makes the job easier and delivers acceptable
performance use it. If not drop down a layer.

Sometimes programming at the lower levels can be useful for learning,
sometimes it can be a fun challenge in its own right. But if you need
to get a job done go with the highest level software support you can find!
Thats why we are using Python and not C, right?



_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to