magic-removal: Merged to [2272]

git-svn-id: http://code.djangoproject.com/svn/django/branches/magic-removal@2273 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/admin_css.txt

@@ -26,10 +26,13 @@ whole group.
 Column Types
 ============
 
+.. admonition:: Note
+
+    In the Django development version, all admin pages (except the dashboard) are fluid-width. All fixed-width classes have been removed.
+
 The base template for each admin page has a block that defines the column
 structure for the page. This sets a class on the page content area
-(``div#content``) so everything on the page knows how wide it should be. So far
-there are three options available, and one special hybrid option.
+(``div#content``) so everything on the page knows how wide it should be. There are three column types available.
 
 colM
     This is the default column setting for all pages. The "M" stands for "main".
@@ -43,27 +46,25 @@ colMS
 colSM
     Same as above, with the sidebar on the left. The source order of the columns
     doesn't matter.
-colM superwide
+colM superwide (removed in Django development version)
     This is for ridiculously wide pages. Doesn't really work very well for
     anything but colM. With superwide, you've got 1000px to work with. Don't
     waste them.
-flex
+flex (removed in Django development version)
     This is for liquid-width pages, such as changelists. Currently only works
     with single-column pages (does not combine with ``.colMS`` or ``.colSM``).
     Form pages should never use ``.flex``.
 
-For instance, you could stick this in a template to make a superwide page::
+For instance, you could stick this in a template to make a two-column page with the sidebar on the right::
 
-    {% block coltype %}colM superwide{% endblock %}
+    {% block coltype %}colMS{% endblock %}
 
-or this to make a liquid-width page (note that ``flex`` replaces ``colM``, so
-both classes are not required)::
-
-    {% block coltype %}flex{% endblock %}
 
 Widths
 ======
 
+**Removed in Django development version (see note above).**
+
 There's a whole mess of classes in the stylesheet for custom pixel widths on
 objects. They come in handy for tables and table cells, if you want to avoid
 using the ``width`` attribute. Each class sets the width to the number of pixels

docs/db-api.txt

@@ -329,7 +329,7 @@ Given an instance of an object, related objects can be looked-up directly using
 convenience functions. For example, if ``p`` is a ``Poll`` instance,
 ``p.get_choice_list()`` will return a list of all associated choices. Astute
 readers will note that this is the same as
-``choices.get_list(poll_id__exact=p.id)``, except clearer.
+``choices.get_list(poll__id__exact=p.id)``, except clearer.
 
 Each type of relationship creates a set of methods on each object in the
 relationship. These methods are created in both directions, so objects that are

docs/django-admin.txt

@@ -92,6 +92,24 @@ Use this if you have a legacy database with which you'd like to use Django.
 The script will inspect the database and create a model for each table within
 it.
 
+As you might expect, the created models will have an attribute for every field
+in the table. Note that ``inspectdb`` has a few special cases in its field-name
+output:
+
+    * If ``inspectdb`` cannot map a column's type to a model field type, it'll
+      use ``TextField`` and will insert the Python comment
+      ``'This field type is a guess.'`` next to the field in the generated
+      model.
+
+    * **New in Django development version.** If the database column name is a
+      Python reserved word (such as ``'pass'``, ``'class'`` or ``'for'``),
+      ``inspectdb`` will append ``'_field'`` to the attribute name. For
+      example, if a table has a column ``'for'``, the generated model will have
+      a field ``'for_field'``, with the ``db_column`` attribute set to
+      ``'for'``. ``inspectdb`` will insert the Python comment
+      ``'Field renamed because it was a Python reserved word.'`` next to the
+      field.
+
 This feature is meant as a shortcut, not as definitive model generation. After
 you run it, you'll want to look over the generated models yourself to make
 customizations. In particular, you'll need to do this:

docs/faq.txt

@@ -342,9 +342,9 @@ Using a ``FileField`` or an ``ImageField`` in a model takes a few steps:
 If I make changes to a model, how do I update the database?
 -----------------------------------------------------------
 
-If you don't care about clearing data, just pipe the output of the
-appropriate ``django-admin.py sqlreset`` command into your database's
-command-line utility. For example::
+If you don't mind clearing data, just pipe the output of the appropriate
+``django-admin.py sqlreset`` command into your database's command-line utility.
+For example::
 
     django-admin.py sqlreset appname | psql dbname
 
@@ -396,6 +396,7 @@ dictionaries in order of query execution. Each dictionary has the following::
     ``time`` -- How long the statement took to execute, in seconds.
 
 ``db.queries`` includes all SQL statements -- INSERTs, UPDATES, SELECTs, etc.
+Each time your app hits the database, the query will be recorded.
 
 Can I use Django with a pre-existing database?
 ----------------------------------------------

docs/settings.txt

@@ -343,6 +343,17 @@ Subject-line prefix for e-mail messages sent with ``django.core.mail.mail_admins
 or ``django.core.mail.mail_managers``. You'll probably want to include the
 trailing space.
 
+ENABLE_PSYCO
+------------
+
+Default: ``False``
+
+**New in Django development version.**
+
+Whether to enable Psyco, which optimizes Python code. Requires Psyco_.
+
+.. _Psyco: http://psyco.sourceforge.net/
+
 IGNORABLE_404_ENDS
 ------------------