#28150 closed Bug (wontfix)
Behavour of django.utils.text.slugify is not consistent between Python 2 and 3 when passed a tuple
| Reported by: | Marcos Diez | Owned by: | nobody | 
|---|---|---|---|
| Component: | Utilities | Version: | 1.11 | 
| Severity: | Normal | Keywords: | slugify unicode enconding | 
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no | 
| Needs tests: | no | Patch needs improvement: | no | 
| Easy pickings: | no | UI/UX: | no | 
Description (last modified by )
After hours of debugging, I realized the behavior of django.utils.text.slugify is not consistent.
On Python 2.7.12 and Python 3.5.2 ( Ubuntu 16.04 LTS)
from django.utils.text import slugify
original_value = ('test trial', )
slug = slugify(original_value)
print(slug) # returns "test-trial"
but on Python 2.7.12
from __future__ return unicode_literals
from django.utils.text import slugify
original_value = ('test trial', )
slug = slugify(original_value)
print(slug) # returns "utest-trial"
This is serious and inconsistent.
Fixing it is not trivial either because it may cause backwards incompatibility.
If I was in charge I would either:
- Do nothing since python 2.7 will be deprecated
- Deprecate slugify and create slugify2 which is not affected by this bug
Thanks for your time,
Marcos Diez
Change History (5)
comment:1 by , 9 years ago
| Description: | modified (diff) | 
|---|
comment:2 by , 9 years ago
| Description: | modified (diff) | 
|---|
comment:3 by , 9 years ago
| Description: | modified (diff) | 
|---|
comment:4 by , 9 years ago
| Resolution: | → wontfix | 
|---|---|
| Status: | new → closed | 
| Summary: | Behavour of django.utils.text.slugify is not consistent → Behavour of django.utils.text.slugify is not consistent between Python 2 and 3 when passed a tuple | 
  Note:
 See   TracTickets
 for help on using tickets.
    
I would call that improper usage since
slugify()expects a string, not a tuple. In any case, since the master branch doesn't support Python 2 and it doesn't look like a fix qualifies for a backport based on our supported versions policy, I think we can close it as wontfix.