Slashdot Mirror

Feh. Captain Sicko uses VS Code on Arch.

That's why he's the best captain.

But I still think the Django Code of Conduct is pretty good for a technical project, almost as good as dmb's interpretation of SQLight's "CoC" (however you pronounce it) above.

These

1. Do not favor, call out or excoriate specific groups based on irrelevant criteria like race, sex, gender, religion or creed
2. Uses technical Roles for actors that anyone could perform at any given time such as developer, customer, manager, contributor
3. Avoids talking about things that are not related to software development (no Solving Hunger in Uganda clause)
4. Avoids talking about things that are not related to the project (no bashing VI in the EMACS CoC and vice versa.)
5. Does not create punishments beyond banning
6. Focuses on encouragement

The first combined with the last two make for powerful anti-power-tripper effects. You can call them SJWs today, absolutists or even temperance movement leaders back in the 1920s in the USA. These are dangerous people who you want to emasculate as much and as soon as possible. Otherwise they will do anything and everything to ensure the Perfect World they envision comes about, even if it is an impossible fiction that requires mile-high piles of dead bodies or mile-long unemployment lines.

1) Summary indicates there are people who are annoyed. No actual links to annoyance.
2) Summary indicates it's quoting a blog post. No blog post linked, just the rules page.
3) The rules page has been around since 2015: https://archive.fo/https://www... - not that "new code of conduct" means that the writer intended to convey it was brand new, but certainly it will be interpreted that way by a lot of folks.
4) FreeBSD had some sort of discussion around it when it came to be in 2015: https://www.phoronix.com/scan.... and it looks like there was some actual internal stuff for project participants that occurred but again, nothing really happened
5) This type of code of conduct isn't really crazy in the OSS world by a simple search. For example, https://www.contributor-covena... shows a plethora of OSS projects that participate and is based on similar principles. Big names OSS participants include Eclipse, Spring, Atom,
6) Microsoft has code of conduct that touches on similar issues: https://opensource.microsoft.c...
7) Github has a guide actively encouraging codes of conduct within communities: https://opensource.guide/code-... and pointing to other OSS projects that have them: https://www.djangoproject.com/...

If you look at FreeBSD's code of conduct in context it really seems like they're late to the party, which may just be a formality (the community norms might already be enforcing these types of rules anyway) or a dramatic change, but there's no way to actually get that from the summary at all.

Well, 100% backward incompatibility isn't always possible, but I think the gratuitous incompatibility in Python 3 is bad. Example: making print a function instead of a special statement. Yes, okay, maybe that would have made more sense 20 years ago when you designed the language. No disagreement, necessarily. But probably a million people or more are now used to typing "print whatever" into the Python interpreter during debugging and when making console Python applications, and inconveniencing all of those people because you think "print(whatever)" is more aesthetically pleasing is just plain inconsiderate.

My (mostly uninformed) opinion is they should have done whatever they needed to do to get Unicode working with minimal drama ... and then stopped there, at least as far as backward-incompatible changes go.

But, hey, they did it, and many people actually like what they did. Including, it looks like, the Django people. You might want to read this if you're curious what some big-name porters think of Python 3 (the attitude seems mostly positive).

Python is a really nice language. For a Python backend, you could start with the Django tutorial. Go through that and a Python tutorial, and try to remember not to program Python as you would C, and you'll have a good start.

For the front end, you'll need to spend some time with HTML, and learn a bit of Javascript/jQuery for any dynamic parts. And if you want it to look any good (and you should care about this because people on the web are generally less forgiving of not caring about the looks), you'll also need to figure out how to mimic a graphical style from a designer with CSS. For hobby stuff, you can just mimic some existing designs, if you're doing it as a business you'd probably want to pay someone to come up with the design, or buy a pre-existing one.

It sounds like a lot of work, but Python + Django is actually lots of fun because you can get a lot done in little time (there's a video of someone doing a wiki site in 20 minutes), and the whole front-end thing is also quite fun because a browser is an interactive beast so you can quickly change things around and see things happen graphically.

Also Django has awesome documentation

Python, Python is my favorite language, however it isn't that good for web.

Go home, comment. You're drunk.

Django, Pylons, Bottle, Flask, TurboGears, Zope, Web2Py...

And that's just some of the popular frameworks..

Again, your assumptions and guesswork about me are entirely unfounded (not that it should matter in considering Drupal):

1. I don't recommend or use WP very often, it's good for simple sites, and I've seen a few Drupal sites that could more easily have been done with WP.
2. I've fixed/maintained a few drupal sites and replaced one big underperforming drupal site (bad developer, compounded by bad usage of drupal IMHO) with rails, taking less than half the resources (CPU/RAM), and half the time to do the same job (500k uniques a year, no not willing to link). These direct comparisons have led me to my conclusion that it is not so much better than other frameworks, quite the reverse.
3. Don't let yourself assume I don't know what I'm talking about to avoid cognitive dissonance, I think I've clearly demonstrated I know the framework and am not some hobbyist WP advocate, and plenty of drupal or ex-drupal developers agree with me, see [1]

A content neutral CMS is a *mistake* IMHO (nodes etc) - most CMS systems are tailored to the problem domain and rightly so. Not doing so leads to bad performance, inflexibility, complex db schemas, and ongoing problems with maintenance. Not many other frameworks try to do this the drupal way; instead a CMS should have pages, users, admin etc, and then you should build your own *domain specific* admin. See Django [2], Rails[3], Play[4] etc. Apparently the core developers have recognised serious problems with drupal even if you don't as they're ripping out the internals in v8 and starting again on many core components. I don't have confidence they'll do better then 8th time round, but YMMV. It's quite possible to build good websites with Drupal, but I think they could be built better, easier, and faster with most other frameworks, even ones which out of the box do far less. If you haven't I would honestly recommend trying one of those in my list and giving it a go to build a simple site just to compare (not another PHP one).

[1] http://benbuckman.net/drupal-excessive-complexity
[2] https://docs.djangoproject.com/en/1.5/topics/db/models/
[3] http://guides.rubyonrails.org/getting_started.html#getting-up-and-running-quickly-with-scaffolding
[4] http://www.playframework.com/documentation/1.0/guide7

What the hell, Soulskill?! After reading the lengthy self-aggrandizing pitch, I hovered over the links, half-expecting them to offer me cheap Nikes o handbags:

http://www.propublica.org/about/
http://slashdot.org/index2.pl?fhfilter= propublica
http://www.propublica.org/nerds/item/our-news-app-tech
http://www.propublica.org/nerds/item/propublicas-news-app-guides
http://www.propublica.org/tools/
http://www.propublica.org/nerds/item/how-to-edit-52000-stories-at-once
http://rubyonrails.org/
https://www.djangoproject.com/
http://www.nytimes.com/2012/06/29/us/cnn-and-foxs-supreme-court-mistake.html

ProPublica is a non-profit corporation, and is exempt from taxes under Section 501(c)(3).

Their public-awareness tactics sure don't look like it.

I second Python: just type in the pseudocode you'd write on a piece of paper, and there is a good chance that it will work just like that in Python.

2D gaming using SDL (and OpenGL 3D, but you have to do the hard work yourself): Pygame
3D drawing/animation/gaming: Blender 3D
(I started by gaming, because that's a fun way to learn a language quickly)

Web: Django
Co-routines: Stackless Python
Maths: NumPy and SciPy
Networking: Twisted

That just scratches the outside of it, but have a look at the above to get an idea of the language.

And Python's documentation is quite good: brief, but everything you need is there - you just need less than you would expect at first. Here are some good tutorials:

Official Python Tutorial
Dive into Python
How to think like a computer scientist?

Hmmm, looks like I've turned into a Python fanboi... Be careful if you try Python, you could fall for it.

I think you are focussing too much on java-style compiler-forced error handling. To me, the essence of try/catch error handling is that you only catch errors if you can deal with them. If you can't (the majority of cases), let is escalate, all the way up to the user (or a log file) if needed. I think there are three sane ways of using a try/catch: (1) to actually deal with the error (this is by far the rarest), (2) mainly in loops of more-or-less independeny actions: to log the error, reset state, and continue working, and (3) at the top level, to log the error and display something less meaningful but less scary to the end user.

I think it is a bad design decision to impose static checking on declared 'throws' statements, because that forces routines to catch stuff that they can't handle, or declare a meaningless list of everything every called routine could ever throw. In essence, it couples the signalling and handling again that exceptions were supposed to decouple.

Another nicety of exceptions compared to return values is that the semanitcs of "something went wrong" is clear. This makes it possible to e.g. have a wrapper function that begins a transaction and commits or rollbacks it depending on the outcome (e.g. https://docs.djangoproject.com/en/dev/topics/db/transactions/?from=olddocs#django.db.transaction.commit_on_success)

You're not that aware of the technology or it would be obvious to you what he meant by: "You make a big list of valid hashes, GPG sign the list..."

You do it this way:
http://www.djangoproject.com/m/pgp/Django-1.2.7.checksum.txt

The stuff between: -----BEGIN PGP SIGNED MESSAGE-----
and:-----BEGIN PGP SIGNATURE-----

are signed by the corresponding signature.

more examples: http://distfiles.gentoo.org/releases/amd64/current-iso/stage3-amd64-20120621.tar.bz2.DIGESTS.asc

I've been able to build some surprisingly sophisticated and full-featured web applications using Python wrapped inside CherryPy and sending the output through Django. Really amazing how much you can do with this, with the added benefit of portability if you ever want or need to move it across platforms.

If portability isn't an issue, by using Python's ctypes you can call almost any back-end Linux, Windows or Mac OS X library for the ability to do almost anything you want.

Like this I guess.

These are obvious choices without better alternative even in the commercial world. All ESRI products, or other products included. ESRI doesn't advertise it, but they are also using GDAL and other open GIS standards.

https://docs.djangoproject.com/en/dev/ref/contrib/gis/tutorial/
I have 10 years of Web, and 5 of GIS experience, and doing consulting now. Let me know if you're interested, and we can have a private conversation.

Seems a bit weird, but I did some digging, and it appear that versions before 1.2.1p2 weren't thread-safe. According to details at http://wolfram.kriesing.de/blog/index.php/2006/multithreading-with-mysqldb-and-weakrefs

From here:

If you are using the older version you will see
bugs. There is no question about this. It's just dangerous in production
environments. So we should be up front about it.

You don't say which version of django you were trying to run, but apparently v0.96 (where the requirement bump happened) they added an option to still run with the old mysql backend, but it wouldn't be maintained in the future..

https://docs.djangoproject.com/en/dev/releases/0.96/?from=olddocs#mysqldb-version-requirement

While I do understand the change, I also understand the frustration of old packages (and various hacks to get newer versions installed). And in the python ecosystem things still happen rather fast. Which is why I've changed to use virtualenv and pip for my development and deployment, and that mostly take all the problems out of it. I have a system that's deployed to gentoo, debian stable and newest ubuntu release - before virtenv and pip it was a royal PITA to keep everything synced up. Now I can more or less deploy it effortlessly on just about any unix. I haven't tried on windows, but most of it should be working there, too.

But generally, making a large python / django app these days without either pip+virtualenv or buildout (or equivalent) is just irresponsible. Both makes it incredibly easy to reproduce an exact python environment, and makes both testing and deploying much, much easier (often, its a 1-2 command deploy, instead of 1-2 days deploy + debug all the different versions)

Anyway.. Sorry to hear of your problems, and I'm a bit sad to see it being necessary.. But there was a reason for it, and there are tools to make it much easier on the sysadmin (lovely feeling knowing that all that crazy stuff is contained in one user directory, and does not touch anything system-wide). And also, next time someone mentions django, maybe you won't dismiss it out of hand :)

I've been using Django for a while now on my web app, having moved away from home-brewed PHP. Very easy to use, and encourages well-written and elegant code.

Nobody else did, so I'll state the obvious.

Python is slow, that is true. From a little experience doing some heavy math, a good rule of thumb is about 1000 times slower than C (for simple stuff, you can safely assume that that's as fast as it gets). The point is that this doesn't mean Python is a bad language, nor that it doesn't have its uses, it only means that when doing heavy duty work, you shouldn't use Python. I wouldn't write a database, a 3D graphics engine, or a quantum mechanics simulation in Python.

That said, 99.99% of what you do these days is not performance-critical. One has to appreciate the fact that if I have a .csv file containing fields in one order, and I need to manipulate the fields a little, rearrange them, and dump them into a different file format - it takes 5 minutes back to back with Python, when it'll take me half an hour in C. Unless that file happens to be quite large, a few gigs at least, there's no way I'll write in C. If I want to solve an exercise, say, finding a fiveleaper's tour, Python will take me much less time. If I want to write an interactive web interface, I'll probably use Django.

The last point in favor of Python is that beyond mere development speed, Python is much, much more user friendly and I believe more beginner friendly. Compare:

#include <stdio.h>
int main() {
        printf("Hello world!");
        return 0;
}

with

print "Hello world!"

Try writing a simple TCP socket chat client/server, and the difference becomes much more obvious.

Keep checking back on this ticket. Composite keys have been a longstanding request in Django and it is being worked on.

I work for a company and we use Django for a large, mission critical project. It's stood up very well so far, we've just had to make sure we know the limitations and design solutions accordingly :)

I checked out the full repository of an open source project I have been tinkering with in both SVN and Git (libgdx). The SVN was MUCH larger than the Git repository on my hard drive (i think 33% more, but I can't remember).

Another example is Django. A Subversion checkout (only trunk, no branches or tags) uses 186 MByte on hard drive, a Git clone uses 87 MByte. That's really astonishing when considering that the git clone contains 6 years of history and 10600 commits.

I can't say my experience matches yours. There are two testing modules shipped by default with Python. Django has integrated support for them out-of-the-box. Django itself has plenty of tests. There are plenty of good third-party testing modules and people are pretty vocal about using them.

On the other hand, I do very strongly get the impression that the lax attitude of "I tried it in my browser so it works" is omnipresent in the Rails community, coming right from the top. Witness the uproar over the Google web accelerator. Rails was just plain wrong to use GET for unsafe operations. But "it worked in a browser", so they didn't see anything wrong with it, even though it was out of spec. GWA came along and triggered data-loss bugs in Rails applications that used unsafe behaviour for GET requests, including 37signals' applications. Rails developers, rather than simply saying "whoops, our bad, we'll fix this ASAP", called GWA evil and wrote code to block GWA. Roll forward a year, GWA changes its behaviour and the blocks don't work any more, the same things happen all over again, and the Rails developers call GWA "scary" and "malicious". These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention.

As for the word "professional" in particular, that's a dirty word in the Rails community.

I can't say my experience matches yours. There are two testing modules shipped by default with Python. Django has integrated support for them out-of-the-box. Django itself has plenty of tests. There are plenty of good third-party testing modules and people are pretty vocal about using them.

On the other hand, I do very strongly get the impression that the lax attitude of "I tried it in my browser so it works" is omnipresent in the Rails community, coming right from the top. Witness the uproar over the Google web accelerator. Rails was just plain wrong to use GET for unsafe operations. But "it worked in a browser", so they didn't see anything wrong with it, even though it was out of spec. GWA came along and triggered data-loss bugs in Rails applications that used unsafe behaviour for GET requests, including 37signals' applications. Rails developers, rather than simply saying "whoops, our bad, we'll fix this ASAP", called GWA evil and wrote code to block GWA. Roll forward a year, GWA changes its behaviour and the blocks don't work any more, the same things happen all over again, and the Rails developers call GWA "scary" and "malicious". These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention.

As for the word "professional" in particular, that's a dirty word in the Rails community.

It exists and it's called Django. Design your tables in Python, and it generates a web-based CRUD interface for you.

he probibly ran into missing documentation on the stuff he wants. Among Open Source projects, this is often what seperates Django from Rails ... click on the links to see which one I think is better, or make your own judgment call. http://library.gnome.org/devel/gtkmm/unstable/

he probibly ran into missing documentation on the stuff he wants. Among Open Source projects, this is often what seperates Django from Rails ... click on the links to see which one I think is better, or make your own judgment call. http://library.gnome.org/devel/gtkmm/unstable/

Python's not so bad. I use it everyday with the Django Libraries. http://djangoproject.com/

If you want a wysiwyg editor for CSS, I think that Stylizer comes pretty close. I am a happy owner of this software. As a fulltime C++ programmer / part-time DJango developer I don't have time to learn / edit CSS any other way.

This particular piece of news doesn't look too good on MySQL, but the GP has it right: MySQL is a brand. This is (unfortunately) important. It's on practically every hosted server, people have heard of it and trust it. I've read the arguments that PostgreSQL is superior, but if you're trying to sell FOSS to someone, it really helps if they've heard of the product. (As a web dev, I have a similar problem trying to sell Django to clients who think they want asp.net.)

Try using Django. kthxbai

To be fair, that's more MTV.

Does that mean web developers who use Django get their money for nothing and their chicks for free?

Try using Django. kthxbai

To be fair, that's more MTV. It still rocks, though.

Hi all,

We had tuned the www.NerdKits.com site to survive slashdottings with its old PHP backend, but we recently started experimenting with some Django. Django is great as a programming framework, but I suppose we have discovered that our tuning of the server settings isn't quite up to handling a Slashdotting! We've temporarily disabled that stuff so the site is back and running. My apologies for the downtime.

- The NerdKits Team

I actually work tech at a big media organization, so this is something I think about constantly, and the article is a perfect example of the media missing the goddamn point.

I actually work tech at a small media corporation, and getting the rest of the industry to wake up is something we've been trying to do for years now. I'm employed by the company which (among other things), publishes the Lawrence Journal-World, of Lawrence, Kansas. Most folks, if they know who we are at all, know us as the original home of the Django web framework, but Django came out of our need to quickly put together custom applications for our online presence, something we've historically done as well as or better than anybody else in the industry.

An example:

Lawrence is home to the University of Kansas; last year, one of our reporters got his hands on a set of documents listing every crime report on the campus for the period 2005-2007. He got these documents (Word docs with embedded tables of the reports) on Wednesday. On Friday I had a demo of a browsable database of the reports ready to go; our UI guys put some polish on it, and we ran it online alongside a story looking into trends and interesting bits we picked up from the data (if you're interested, I gave a lightning talk at PyCon last year which covered, in whirlwind fashion, how it was put together. So far we don't have data for 2008, but I'd love to go back and add it, and see a followup story).

We do that kind of thing all the time, and it's neither burdensome nor useless (and we have a bookcase full of shiny things given to us by industry award groups -- two examples I can pull off the top of my head were for this feature on the demise and aftereffects of mining in southeastern Kansas, and our retrospective on the KU basketball team's championship season last year).

People really seem to like this stuff and find it useful (and our former lead developer is recognized as having more or less invented what's now called "database-driven journalism"; these days he's turning out even more interesting uses for online data). Unfortunately, the industry as a whole is stubbornly stuck with the mindset that the printed paper is and always should be their "main product", and most folks are burdened with tech solutions that are far too cumbersome to be put to these sorts of uses.

Anyway, my point is that not all of the stuff going on these days is "Web 2.0 widgets"; there are plenty of us who, when given the chance, are trying to help journalists save themselves from extinction by bringing tech into the newsroom in actually useful and interesting ways.

Since both the Django and python communities are very active, I suspect this will be remedied soon. I cannot wait.

You might end up in trouble, then; as explained by the FAQ, it'll be a while before Django officially supports Python 3.0.

Remember: even the Python developers themselves are talking about a migration timeline of years, rather than a simple "next version of every library will be on Python 3" (which just isn't possible with any kind of responsible release process). See this summary I posted on django-developers for some more information.

Everything your code does is something the framework doesn't do for you: the real problem is not customization, but how cleanly the framework allows you to extend it, how stable the interface (between the framework core and your extensions) is, and so on.

That's why I'm surprised to hear people recommend switching from Rails to Django. My experience in going through that route is that Django is less flexible and harder to customize than Rails. For example, in both frameworks you can write custom SQL queries, but while find_by_sql in Rails returns fully-formed model objects (as long as you fetch all the needed attributes in the query), raw SQL queries in Django only return raw data tuples. You cannot integrate your custom SQL with Django's ORM (ie, you cannot get a Django model object from cursor.execute), so you end up getting a bunch of IDs from your custom SQL, and then passing them to Django so it can query the database again for the same objects, using two queries to do the work of one.

Next time I want to make a web application in Python, I'm going to skip Django and look into Pylons instead.

Well at my college we are all Linux, they start you off with C++, but IMO I think they should start off with Python to ease in the freshmen. I would suggest Django/Python for web programming (I am in the process of learning), also PHP (which I love and currently do all my side projects in) as for non web programming I would go with C/C++, and dare I say Java.

You can find Python book online, and Django book as well.

For a good IDE I really like Geany, it works well with a Linux system, and it's light weight. It looks for installed compilers so you don't have install anything on top it as long as you have all the stuff you needs like GCC, OpenJDK, etc.

This is correct. The issue is in fact addressed in Django's official FAQ.

If you're hungry for acronyms, you might say that Django is a "MTV" framework - that is, "model", "template", and "view." That breakdown makes much more sense.

At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.

He ignores Django's own take on their differences with traditional MVC, and prefers to just bash a straw man.

I haven't had the time to read the whole piece yet, but I strongly doubt the author's intent was to ignore Django's take on MVC or even bash it. Him being a Django core developer and all...

And he clearly states that before he even goes into Djangos documentation and concept of MVC.

He ignores Django's own take on their differences with traditional MVC, and prefers to just bash a straw man.

Author is Pedantic... And does quite a bit of complaining about Django without completely demonstrating his point.

Malcolm's blog assumes that the reader has a *very* good understanding of the django codebase. That's understandable, given that he rewrote most of the ORM prior to the recent 1.0 release, and most of his readers know it.

I'm still foggy about his complete idea of what he believes the original interpretation of a "Controller" is, which is really the heart of the matter and where most people seem to disagree.

His basic point is that no one actually knows what the controller *is*. The term is so poorly applied that it loses all meaning.

Really, this is a long standing point in the django community, and can be traced back to the original authors of the framework. Because django uses three primary modules, it gets labeled MVC. It doesn't actually follow that pattern very closely, so the authors took to referring to it as MVT (model, view, template).

From the django FAQ:

In our interpretation of MVC, the "view" describes the data that gets presented to the user. It's not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It's a subtle distinction.

Where does the "controller" fit in, then? In Django's case, it's probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.

At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that's most logical to us.

Malcom is just pointing out that MVC comes with a lot of baggage, and doesn't really help to get stuff done.

I recommend you just develop a web-based solution using Django. (Or any other web platform of your choice, but Django is the one I have used and I love it. Django makes it easy to do whatever I have needed to do, and I have done some unusual stuff with it.)

Then, you can use any phone with a decent web browser, plus you could use a PDA, a netbook, or anything else. You likely will live in the house for many years, and technology certainly will evolve... a simple web solution is pretty future-proof.

steveha

It's too bad everyone and their dog are excited about Ruby on Rails, when a great platform like Django is out there as well.

I use Django on my own site, and CakePHP (a poor RoR clone) at work. While using PHP has advantages, CakePHP is really not anywhere near Django in terms of the ORM stuff and actually using your data in any complex way.

The one really great thing about Django is that it's consistent. There is usually one way of doing things, instead of a million different ways that apply in different situations.

Take a look at the Django tutorial:
http://docs.djangoproject.com/en/dev/intro/tutorial01/

And the Django book:
http://www.djangobook.com/

I don't think you'll be sorry.

PS. And on the whole Python indentation=block thing... It's not perfect, but only use spaces and it won't be a problem.

Still, if you're writing system software

(e.g. a web server,

I tend to agree, but the folks at Plone and Zope would probably disagree. That's easily one of the most powerful CMS packages, with the only competitor in the same league being Typo3. On the other hand, Django recommends bog-standard Apache.

daemon control software,

I have no idea why you think daemon control software needs the performance of C/C++.

filesystem indexer, etc)

I've actually written a filesystem indexer in Python as part of an image management program (think ACDSee). Obviously the hashing algorithms and performance critical parts are written in C/C++, but there is no reason not to write the rest in Python. You spend most time waiting for the disk I/O...

or large desktop software (Photoshop, Microsoft Word, KDE),

Again, the only one of those that shouldn't be written in Python is KDE (parts of it could be). Image-handling code should be written in C/C++, but the GUI doesn't need to be. My (currently unreleased, but fully-functional) image management program is faster than ACDSee, which has more to do with loading the GUI without blocking waiting for the image to load than it does with using C++. It also uses less memory because I only load the thumbnails that are displayed on screen into memory... Actually it blows the old-school application ACDSee out of the water for performance. Again, for image manipulation, I would use a C/C++ coded image library such as ImageMagick, which has bindings for Python.

then it would be madness to choose Ruby/Python over C++.

Not hardly.

So you're not personally familiar with python-based web development. There are a great many people out there that are though: Django, Pythons, Turbogears, Zope are all great places to start.

Just to follow up: Python has two flavors of tests -- unittest, which was originally the PyUnit software you've already been pointed to, and doctest which lets you write interactive examples -- and Django's test framework has baked-in support for both of them, along with extension points to plug in your own system if you prefer. There's also a dummy HTTP client which can send requests and inspect the responses being sent back (including verifying data-processing from the backend), and a co-worker of mine has released some software which generates a test suite from a live browser session to ease creation of your tests.

Personally, I've always felt that Python's doctest system is one of the greatest things since sliced bread; for example, it lets us produce a single document which in one context can be processed as API documentation but, in another, is executable as a unit test suite for the features it's documenting.

Just to follow up: Python has two flavors of tests -- unittest, which was originally the PyUnit software you've already been pointed to, and doctest which lets you write interactive examples -- and Django's test framework has baked-in support for both of them, along with extension points to plug in your own system if you prefer. There's also a dummy HTTP client which can send requests and inspect the responses being sent back (including verifying data-processing from the backend), and a co-worker of mine has released some software which generates a test suite from a live browser session to ease creation of your tests.

Personally, I've always felt that Python's doctest system is one of the greatest things since sliced bread; for example, it lets us produce a single document which in one context can be processed as API documentation but, in another, is executable as a unit test suite for the features it's documenting.

Just to follow up: Python has two flavors of tests -- unittest, which was originally the PyUnit software you've already been pointed to, and doctest which lets you write interactive examples -- and Django's test framework has baked-in support for both of them, along with extension points to plug in your own system if you prefer. There's also a dummy HTTP client which can send requests and inspect the responses being sent back (including verifying data-processing from the backend), and a co-worker of mine has released some software which generates a test suite from a live browser session to ease creation of your tests.

Personally, I've always felt that Python's doctest system is one of the greatest things since sliced bread; for example, it lets us produce a single document which in one context can be processed as API documentation but, in another, is executable as a unit test suite for the features it's documenting.

This is why I don't do production work with newer frameworks like these. The next time I need to change something, half of my application could be broken!

This is why we have a document explaining which APIs are finalized and which may change prior to 1.0.

For example, the FileField isn't friendly for organizing things by users

Which will change with the swappable file backends being introduced by ticket #5361, which is scheduled to land for 1.0 beta (and thus to be part of the 1.0 release in September). That ticket's been held up a bit by a related piece of work which landed not too long ago: configurable file-upload handlers.

For example, the FileField isn't friendly for organizing things by users

Which will change with the swappable file backends being introduced by ticket #5361, which is scheduled to land for 1.0 beta (and thus to be part of the 1.0 release in September). That ticket's been held up a bit by a related piece of work which landed not too long ago: configurable file-upload handlers.

An object-relational mapper so you don't have to write SQL.

You mean that impedance mismatch misuse, when you still write SQL, once you use custom stored procedures?.. ORM is not any Good Thing for advanced use. In Python it still more sweet, but in Java all this Hibernate and TopLink circus is just a nightmare of complexity over stupid triviality. Something very similar to SQLObject and SQLAlchemy, though I agree it is much lighter (due to Python itself)...

It's own template language. Althouh, you can use any other template language you want.

Is it really truth? The only template is really good -- ZPT from Zope, that... won't be used with Django. Maybe it was fixed already, honestly I do not know, but this bug is kind of scary and response from Django developers kind of stupid: http://code.djangoproject.com/ticket/1140

I will add to my above post, that in Django, it is very easy to extend / override almost any part of the framework. Within a week of using it, I was writing my own custom HTML widgets, compound data fields, and even custom added support for custom DB column types. Now, I know that ActiveRecord allows you to do some of these things, but it's not at all easy or intuitive.

But, hey, if you love Ruby, use Rails.

The thing everyone has to remember about Django vs. Rails, is that this is really more a Python vs. Ruby debate. The nature of the languages has affected the design of the corresponding framework in dramatic ways.

That said, I think that, if Rails were done all over again, it could learn a lot from Django.

Check out Snakes and Rubies. (Google video version.) It was a pair of presentations on Django and Rails. Good stuff. This was in December of 2005. Yeah, Django's been around for a while, despite the comments about it being a "young" framework.