That would work, except, as you say, computed values throw it off, and,
at least in my opinion, instantiating fields in the same way they're
defined in the models.py is the most sure-fire way to get things working.
It also has the nice side-effect of making the stored values of the
fields more hu
On Sat, Feb 21, 2009 at 5:48 PM, Andrew Godwin wrote:
>
> Heh, as I expected.
>
> So, when I first started on South, I initially tried introspecting the
> various fields to drag their parameters out of wherever they had been
> saved to - for example, max_length in a field goes to self.max_length.
Heh, as I expected.
So, when I first started on South, I initially tried introspecting the
various fields to drag their parameters out of wherever they had been
saved to - for example, max_length in a field goes to self.max_length.
Then, you have the special cases for Django core fields. For exa
On Sat, Feb 21, 2009 at 2:54 PM, Andrew Godwin wrote:
>
> Hello everyone,
>
> I'm currently working on the next version of South
> [http://south.aeracode.org], and I need some test fodder for our new
> models.py parser - rather than our previous approach using regexes and a
> reasonable amount of
Hello everyone,
I'm currently working on the next version of South
[http://south.aeracode.org], and I need some test fodder for our new
models.py parser - rather than our previous approach using regexes and a
reasonable amount of hope, this time it's being done properly, using the
python parsing
5 matches
Mail list logo
