Changes between Version 156 and Version 157 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
02/25/2008 12:04:21 AM (7 years ago)
Author:
gwilson
Comment:

noted [7153]

Legend:

Unmodified
Added
Removed
Modified
  • BackwardsIncompatibleChanges

    v156 v157  
    5252 * [7091] Feb 5, 2008 [#Changees_ARtoes-arinLANGUAGES Change es_AR to es-ar in LANGUAGES]
    5353 * [7133] Feb 18, 2008 [#ChangedField.get_internal_typedefault Changed Field.get_internal_type() default]
     54 * [7153] Feb 24, 2008 [#Changeddecoratorstoinheritattributesofthefunctiontheywrap Changed decorators to inherit attributes of the function they wrap]
    5455
    5556== Database constraint names changed ==
     
    572573
    573574If you were subclassing an existing model field and were relying on the fact that the {{{Field.get_internal_type()}}} method would return your class name by default, you will need to alter your code to explicitly say that (i.e. to return the string you want). It seemed that most subclassing of existing fields (even in Django core) were using the parent's column type, so we've now set things up to exploit that. Thus, inheriting from a {{{CharField}}} results in {{{get_internal_type()}}} returning ''CharField'', etc.
     575
     576== Changed decorators to inherit attributes of the function they wrap ==
     577
     578If you were using one of Django's decorators and relying on decorated functions/methods to have the name (`__name__`), docstring (`__doc__`), or attributes (`__dict__`) of the decorator, then you need to change your code to work off the name, docstring, or attributes of the decorated function instead.  If you are using Python 2.3, you don't need to worry about the changing of the decorated function's name since Python 2.3 does not support assignment to `__name__`.
Back to Top