Proposal: unique by default on SlugFields
Perhaps it's just me, but I've very rarely wanted a SlugField that wasn't unique. Would this not be a sensible default? I realise that a lot of apps will rely upon this default, but objectively speaking would this not be better? Perhaps this change would be appropriate for django 2.0. At the moment, slug = models.SlugField()creates a non-unique field, and if you want it to be unique, then you must add unique=True. I feel this is wrong. It seems to me that unique should be default, and if you don't want a unique slug, you should explicitly state that: slug = models.SlugField(unique=False) I've added an issue on the tracker for this: https://code.djangoproject.com/ticket/18525 I realise this may be a contentious issue...or that I may even get shot down in flames on this one ;P Go easy on me! :) What do you all think? Charlie. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/wb1YDBfDUO4J. 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.
Re: Proposal: unique by default on SlugFields
On Wednesday, June 27, 2012 7:15:03 AM UTC-4, Meshy wrote: > > Perhaps it's just me, but I've very rarely wanted a SlugField that wasn't > unique. Would this not be a sensible default? I realise that a lot of apps > will rely upon this default, but objectively speaking would this not be > better? Perhaps this change would be appropriate for django 2.0. > > At the moment, slug = models.SlugField()creates a non-unique field, and > if you want it to be unique, then you must add unique=True. I feel this > is wrong. > > It seems to me that unique should be default, and if you don't want a > unique slug, you should explicitly state that: > slug = models.SlugField(unique=False) > I'd agree that slugs are often unique, but I think it's just as common that they are unique together with another field (think blogs -- /blog/2012/06/27/some-slug/ -- where the slug is unique_together with the date). For this case, you'd have to remember to specify unique=False *and* unique_together. > I've added an issue on the tracker for this: > https://code.djangoproject.com/ticket/18525 > > I realise this may be a contentious issue...or that I may even get shot > down in flames on this one ;P Go easy on me! :) > > What do you all think? > It doesn't seem like a burden to have to say unique=True if you truly want a singularly unique slug. Making it explicit, aside from being good python zen, also helps to see the natural keys of your model at a glance. Dan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/8V3D_HcVhf8J. 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.
Re: Proposal: Add some extensibility / decoupling features to Django templates
On Sunday, June 24, 2012 3:02:05 PM UTC-7, Alex_Gaynor wrote: > > > > On Sun, Jun 24, 2012 at 2:50 PM, Jacob Kaplan-Moss wrote: > >> On Sat, Jun 23, 2012 at 7:17 PM, Yo-Yo Ma >> wrote: >> > Without changing any of the existing functionality or settings in >> Django, >> > refactor the template system to use an ``Environment`` class (something >> akin >> > to Jinja2's ``Environment``) which takes a list of loaders, and a >> number of >> > other arguments. Then, instantiate this class, using the provided >> settings, >> > and use it for all the default functionality (the admin, >> render_to_response, >> > CBV template access, etc.). This would allow developers to make their >> own >> > ``Environment`` instance with different arguments, request-specific or >> > otherwise, and without having to do a lot of evil things. >> >> Sounds great - I'd love to see a patch! >> >> Jacob >> >> -- >> 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. >> >> > This is a good idea, I think there's even a ticket (probably, but not > definitely filed by either myself or Carl Meyer) on this! > > Alex > Indeed there is: https://code.djangoproject.com/ticket/17093 -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/fXhEsNBSz58J. 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.
Re: Proposal: unique by default on SlugFields
On Wed, Jun 27, 2012 at 7:15 PM, Meshy wrote: > Perhaps it's just me, but I've very rarely wanted a SlugField that wasn't > unique. Would this not be a sensible default? I realise that a lot of apps > will rely upon this default, but objectively speaking would this not be > better? Perhaps this change would be appropriate for django 2.0. > > At the moment, slug = models.SlugField()creates a non-unique field, and if > you want it to be unique, then you must add unique=True. I feel this is > wrong. > > It seems to me that unique should be default, and if you don't want a unique > slug, you should explicitly state that: > slug = models.SlugField(unique=False) > > I've added an issue on the tracker for > this: https://code.djangoproject.com/ticket/18525 > > I realise this may be a contentious issue...or that I may even get shot down > in flames on this one ;P Go easy on me! :) I don't think it's particularly contentious -- I'd certainly pay your premise that Slugs are almost always unique (although as Dan pointed out, they're often unique with other fields). However, I would make two comments: * There's a backwards compatibility issue. We can't just reverse the value of the setting, because it would break all existing code. There might be some ways to introduce it slowly (e.g., the value of an "undefined" unique setting changes over a couple of releases). However, even if we were going to go down this path, we still need to balance the inconvenience of the change against the benefits. * Explicit is better than implicit. By default, database fields won't be unique -- you need to explicitly make them unique. Even though there's a little bit more typing involved, there's something to be said for being explicit about making every field unique. If we had a clean slate, it might be worth reconsidering the default. However, at this point, the behaviour of SlugField has been the way it has for 6 years, and it has been, at worst, a minor inconvenience. For me, given the inconvenience involved in making the change, this issue just doesn't rise above "meh" level. Yours, Russ Magee %-) -- 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.
Re: Newline stripping in templates: the dnl way
On 2 March 2012 09:45, Carl Meyer wrote: > Same reason any ticket stalls - it seems that nobody felt strongly > enough about it to put the time into reviewing and thoroughly testing > the patch and marking it Ready for Checkin. If you'd like to see it in > (post 1.4 at this point, of course), feel free to do that! Done! :-) I've created a new version of the patch against Django 1.5-dev, which passes all tests, etc... I've attached it to the ticket directly: https://code.djangoproject.com/ticket/2594 Cheers, Leon -- 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.
