I did actually just come up with two problems involved in having a
customizable separator for slugify:
1) SlugField would also have to take a parameter to define the separator so
that there wouldn't be inconsistencies in the output of SlugField and
slugify. This seems like it would be a big pitfall for potential user error.
2) For users who have been using slugify as-is, but then change to a new
separator: if you stored a URL path component in your DB with a SlugField
then changed the slugify separator from a dash to a something else, not only
would you end up with an inconsistent mix of things in your DB, if you ever
tried to reconstruct that same URL using slugify you wouldn't come up with
the same result.
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
