On Wed, Jun 26, 2013 at 11:47 PM, Patryk Ściborek <[email protected]>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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
