On Wed, Jun 26, 2013 at 11:47 PM, Patryk Ściborek <pat...@sciborek.com>wrote:
> W dniu środa, 26 czerwca 2013 17:26:12 UTC+2 użytkownik Carl Meyer napisał: > > >> Do you have any new information to justify why the existing resolution >> of #2239 should be reconsidered? >> >> I think the existing resolution is correct. This seems like a perfect >> case for a third-party field class. I don't think the need to represent >> MAC addresses in the database is common enough in web development to >> warrant inclusion in Django core. >> > > Hi! > > I agree it can be solved by third-party code - this is the way I do it > right now. Unfortunately there is one thing which can't be done this way - > database introspection. Maybe I'm wrong and it is possible to extend > introspection code? > > If a lack of introspection is the problem, then that's the problem that should be fixed. If we add a MAC field, we only address *your* introspection problem; if we add a generic API for introspection, we fix *everybody's* introspection problem. Fixing the larger problem will always garner more support than a band-aid solution for an immediate problem. I concur with the sentiment expressed in this thread -- adding a MAC field isn't something we should be aiming for in core, if only because it's not a field type that is universally available across all database backends. However, adding API entry points that would allow end users to define fields that have their own introspection rules is *definitely* something I would support for core. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
