> * it removes the ability to provide multiple markup_types on a given field
No if properly implemented. Again, see FileField upload_to for example. > * what is unpythonic about taking in two extra parameters to customize the > field? All markup functions take different arguments. Also different versions of one markup take different arguments. The nonsense of your way is already there in current render_markup: REST doesn't use self.sanitize and TEXTILE doesn't use self.extra_options. Even if you provide default behaviour for contrib.markup why not accept callable for markup_type as Marty suggested? > It seems like the argument that this field isn't generic enough is > akin to suggesting that django.contrib.markup's templatetags aren't valuable > because there are cases where one needs to support a different type of > markup. The argument is that this field can became more generic, extendible and better designed with very few and easy changes. But you just don't want accept it. Very strange point of view. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
