I wanted to list a bunch of features of an ideal environment for web development. Well, here's some features, in no particular order. This only covers a few aspects, sometimes at a high level and sometimes at a fairly low level. Whether I intended it or not -- I actually forget -- Little of it is Python specific. It could apply just as well to Perl, Ruby, or Lisp as it would to Python (PHP, Java, and .NET/ASP already have a slightly different take on many of these issues, and in various ways I suspect many of these things wouldn't be applicable -- Smalltalk, except perhaps for GNU, is so far out of the norm that it's hard to usefully include). These are mostly focused on the development tools and conventions, not such petty things as code (silly human, code is for monkeys!)

I plan to expand this list as I think of more things; maybe I'll store it someplace more permanent. I'm sure I've left out large areas that are important aspects to development.

1. It should be easy to figure out where things in the rendered HTML come from. This could probably be handled with comments. Of course, they could only be inserted in a debugging mode. They should be automatic, not just conventions the template writers use.
2. Templates should have a search path, where typically the first paths on the path are specific to the installation or site.
3. There should be an easy way to clone the application-installed template into that site directory. There should be 3-way merges so you can integrate changes to the application templates into your customized templates. Obviously source control should be applied here too. Maybe all this happens through a web interface, maybe not.
4. Internationalization files go through the same process, as well as CSS. I don't see a good reason for Javascript, though. CSS should not be rendered unless there is a very good reason, it should be a static file directly served. DItto Javascript. This way there is a direct mapping from these files to files on disk.
5. Everything should be refreshed immediately (i.e., changes are viewed on next reload). Syntax errors should produce useful messages (including syntax errors in Python that might make the application unloadable).
6. Session information should never be lost on reloads.
7. Runtime errors should show tracebacks that include any and all template contexts.
8. They should show other context as well, insofar as it is possible. More information accumulated statically is better, since it can be viewed post-mortem.
9. Output should be verified in debugging mode, like HTML validity, Javascript linting, CSS checking, etc.
10. I don't like hiding HTML from people, but including Javascript and CSS files is boring. Javascript package management sucks. The framework should help here (just a little). Also, when not in debugging mode, it could potentially do things like combine/compress the Javascript.
11. Breakpoints? I'm not sure that's the easiest way to go about things; nice, sure. But I think it may be sufficient (maybe even better) if you could get the same kind of traceback you get on an error by putting in a breakpoint-like statement.
12. Log messages should viewable in the context of the page.
13. It should be really easy and compelling to run the application in a branched form in a testing environment, and to synchronize these changes. Obviously this requires version control. Maybe it requires decentalized version control, or maybe just something like svn with a file: scheme. There should be a variety of tools to make the specific process in relation to this environment and applicaition easy and well directed. (Which might mean, for instance, not worrying about log messages and just committing on behalf of the user)
14. Though it's not as important as templates, obviously backtracking to the Python code/controller is important.
15. Lots of testing support...
16. Easy collection of unit tests and doctests.
17. Any external state -- databases in particular, but could also include filesystem or other state -- should be easy to set up for tests, and easy to maintain.
18. Consider all the various categories of tests that are useful. There's lots of them, with vague distinctions, but I'll say: stateless programmer tests (unit and doctests), stateful programmer tests, acceptance tests, tests to confirm an installation is correct, general lint/style tests, acceptance tests, UI tests, Javascript/in-browser tests, externally-applied tests that an application is alive and working, load tests. There's frequently overlap, and large pieces can be shared between these categories of tests, but often a category or two of tests is left out.
19. Some way to act on some of these tests, particularly operational tests.
20. Reports on these tests.
21. Javascript tests should be available in some standard fashion, or linked in from somewhere.
22. Easy setup of a test environment. This might often rely on sqlite or other easy-to-set-up pieces of code.
23. Every application should have a URL that, when fetched, will do some non-destructive self-test. This is really enough for an operational test. This opens up the app to DoS, so it should probably be protected in some way.
24. Every app installation should get a secret. Multiple instances of a single installation (e.g., when balanced) all get the same secret. The framework should make sure this is available -- managing this on a per-application or per-component basis is annoying.
25. Things should generally be idempotent. When you do things, if they are wrong or broken or whatever, you should just be able to undo them and/or do them again without problem. And if you do something right, then do it again, the second invocation should have no effect (or warn, or provide options -- first do no harm). This isn't a specific feature, but generally it's just good UI for nearly anything.