django-nonrel/djangotoolbox — Issue #18: Type conversions refactor bis
Author: wrwrwr
Created: 2012-02-20 14:54:01+00:00
State: open

Type conversions refactor split into more logical parts, plus a complete PEPification and style normalization and some additional cleanup. The actual changes are described in the [original issue](https://github.com/django-nonrel/djangotoolbox/pull/16) -- all is still relevant including the warning at the end. The new branches are here:

https://github.com/django-nonrel/djangotoolbox/compare/feature/type-conversions-refactor-2
https://github.com/django-nonrel/djangoappengine/compare/feature/type-conversions-refactor-2
https://github.com/django-nonrel/mongodb-engine/compare/develop...feature/type-conversions-refactor-2

Hopefully you'll find reviewing them commit-wise doable, unlike before. The [additional nonrel branch](https://github.com/django-nonrel/django-nonrel/compare/feature/drop-related-db-type) is optional, it depends on the refactor, but not vice versa.

First commit on each branch contains all the pedantic stuff; there are no actual changes in these commits -- other than reflowing, capitalizing & dotting, blank adding there is some method reordering, variable renaming, additional comments, one unused internal method dropped and some small blocks of code rewritten for better readability. If anything in these first commits raises any doubts I'm going to separate it.

The code style chosen is not really any better than what it was, but it is consistent across toolbox and both engines (and dbindexer is to follow). I've based it on [PEP8](http://www.python.org/dev/peps/pep-0008/), [PEP257](http://www.python.org/dev/peps/pep-0257/), [Django](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/) & [Google](http://google-styleguide.googlecode.com/svn/trunk/pyguide.html) code styles (generally trying to stick with the first one unless there was some good reason not to). There are some some pros of cleaning up and normalizing things this way:

* following commits should be more readable, as the temptation to include stylistic changes should be smaller;
* you may run the [pep8 verifier](https://github.com/jcrocholl/pep8) on `.` to check if your code is fine and dandy (use `--exclude="multiple_database"` for Mongo, ignore W602);
* and also you may comfortably place a traceback and an editor side-by-side, even on a small monitor, and maybe you'll find yourself scrolling a bit too much and reading another class than you though you were a bit less often ;-)

The additional cleanup includes:

* separating parts that are not relevant to the issue (I've committed the set serialization test and EmbeddedModelField.update fixes to the develop branch, tests for the natural usage of ListField with ForeignKeys are on a separate branch);
* some further simplifying of fields code, namely this commit: https://github.com/django-nonrel/djangotoolbox/commit/5fce56f12e9fbfe5691e2db7fc8aecc6ded39c38;
* and of GAE code: https://github.com/django-nonrel/djangoappengine/commit/8f81ef7f1e14de12526aa6208872e8b812a0416e;
* I've renamed `DatabaseCreation.nonrel_db_type` to just `db_type` after realizing that the parent method has been added by nonrel, moreover back-ends can now actually work without the [`related_db_type` changes](https://github.com/django-nonrel/django-nonrel/compare/develop...feature%2Fdrop-related-db-type). Probably I'll propose letting back-ends override `Field.db_type` in this way to Django (replacing the [#17336 ticket](https://code.djangoproject.com/ticket/17336)).
* Removing or explaining some TODOs.