Changes between Version 156 and Version 157 of BackwardsIncompatibleChanges

Timestamp:

Feb 25, 2008, 12:04:21 AM (17 years ago)

Author:

Gary Wilson

Comment:

noted [7153]

BackwardsIncompatibleChanges

@@ -52 +52 @@
  * [7091] Feb 5, 2008 [#Changees_ARtoes-arinLANGUAGES Change es_AR to es-ar in LANGUAGES]
  * [7133] Feb 18, 2008 [#ChangedField.get_internal_typedefault Changed Field.get_internal_type() default]
+ * [7153] Feb 24, 2008 [#Changeddecoratorstoinheritattributesofthefunctiontheywrap Changed decorators to inherit attributes of the function they wrap]
 
 == Database constraint names changed ==
@@ -572 +573 @@
 
 If 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.
+
+== Changed decorators to inherit attributes of the function they wrap ==
+
+If 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__`.