[Django] #26796: Add a check for limit_choices_to on ManyToManyField with an explicit through model

[Django]

#26796: Add a check for limit_choices_to on ManyToManyField with an explicit
through model
+
   Reporter:  charettes |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (System checks)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 As
 
[https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.ManyToManyField.limit_choices_to
 documented]:

 > limit_choices_to has no effect when used on a ManyToManyField with a
 custom intermediate table specified using the through parameter.

 `ManyToManyField._check_ignored_options` seems like the perfect place to
 add this check.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.37b6e103be1b0e98908ab885e94167fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26795: Refactor code in tests.migrations.test_autodetector

[Django]

#26795: Refactor code in tests.migrations.test_autodetector
-+-
 Reporter:  akki |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by akki):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.a1173cb1dc405372c6b706e43a269bd3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26795: Refactor code in tests.migrations.test_autodetector

[Django]

#26795: Refactor code in tests.migrations.test_autodetector
--+
 Reporter:  akki  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Testing framework |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Recently, while working in
 
[https://github.com/django/django/blob/c2e62fd1aed093c4d9ff84e3d86e6a85c8aa1917/tests/migrations/test_autodetector.py
 django.tests.migrations.test_autodetector] I noticed that the following
 code is getting repeated approx 100 times:

 {{{
 #!python
 before = self.make_project_state([self.author_name])
 after = self.make_project_state([self.author_name_longer])
 autodetector = MigrationAutodetector(before, after)
 changes = autodetector._detect_changes()
 }}}

 I think it can be used as a simple method of the class cutting down a
 large chunk of code. Something like:
 {{{
 #!python
 def get_changes(self, before_states, after_states):
 before = self.make_project_state([self.author_name])
 after = self.make_project_state([self.author_name_longer])
 autodetector = MigrationAutodetector(before, after)
 return autodetector._detect_changes()
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.4833418f33cd945e8f39c9802adb2af6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26790: Move BaseUserManager.normalize_email() to AbstractUser

[Django]

#26790: Move BaseUserManager.normalize_email() to AbstractUser
--+
 Reporter:  tam0407   |Owner:  tam0407
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  normalize_email   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by squallcs12):

 currently `BaseUserManager.normalize_email()` is a classmethod, from `cls`
 we can't get `model` attribute like `manager_instance.model`. Thus when we
 move `normalize_email` to `AbstractUser`, I don't know how to make a
 extendable call to `AbstractUser. normalize_email()` from classmethod
 `BaseUserManager.normalize_email()` for backward compatibility.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2af6ee33c07c79ea01b6e253e8a4494e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26779: i18n_javascript should take extra_context as argument

[Django]

#26779: i18n_javascript should take extra_context as argument
--+
 Reporter:  shabda|Owner:  shabda
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by tobiasmcnulty):

 * needs_better_patch:  0 => 1
 * needs_tests:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.faaef00acd39d1fd4b14128e02c3d197%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26765: Etags should not be added when no-store is used

[Django]

#26765: Etags should not be added when no-store is used
-+-
 Reporter:  marfire  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tobiasmcnulty):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 Reviewed & notes left on the PR:
 https://github.com/django/django/pull/6810

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.cc25350f4b7e192188684655120dfc9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25292: "'str' object has no attribute '_meta'" crash in ManyToManyField.through_fields check

[Django]

#25292: "'str' object has no attribute '_meta'" crash in
ManyToManyField.through_fields check
-+-
 Reporter:  thbarrons|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.8
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mtomiyoshi):

 * status:  closed => new
 * resolution:  needsinfo =>


Comment:

 I ran into this bug today using Django 1.9.7, I created a sample project
 to reproduce it.

 It doesn't happen when you use SQLite, I'm not sure about other databases.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5a20b1b6925e1c6cc14939a8dc3f8fa4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25292: "'str' object has no attribute '_meta'" crash in ManyToManyField.through_fields check

[Django]

#25292: "'str' object has no attribute '_meta'" crash in
ManyToManyField.through_fields check
-+-
 Reporter:  thbarrons|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  1.8
  checks)|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mtomiyoshi):

 * Attachment "django-error.tar.gz" added.

 Sample project

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.35ee483318142a054576a2bac01538e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25920: Add number formatting support for locales that use non-uniform digit grouping (e.g. India)

[Django]

#25920: Add number formatting support for locales that use non-uniform digit
grouping (e.g. India)
--+
 Reporter:  dbinoj|Owner:  jasisz
 Type:  New feature   |   Status:  closed
Component:  Internationalization  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:  en-IN | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"b5a1c3a6f50362b57603e1833e44bff5628dde3c" b5a1c3a]:
 {{{
 #!CommitTicketReference repository=""
 revision="b5a1c3a6f50362b57603e1833e44bff5628dde3c"
 Fixed #25920 -- Added support for non-uniform NUMBER_GROUPING.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dc959c98d9c46613708cb70ad8538793%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26794: Migrating ForeignKey to OneToOneField creates extra index on PostgreSQL

[Django]

#26794: Migrating ForeignKey to OneToOneField creates extra index on PostgreSQL
+--
 Reporter:  jdufresne   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Duplicate of #26090

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a0025ef2dec88f34ef6c13b158186bc8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26793: 1.10b1 affected with #22853

[Django]

#26793: 1.10b1 affected with #22853
-+--
 Reporter:  strelnikov   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Migrations   |  Version:  1.10
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => needsinfo
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Please provide a sample project or steps to reproduce. I followed the
 steps in the description of that ticket and didn't reproduce it.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.14a169b9bc0754fa97b93c8bdc82edda%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26719: UserCreationForm doesn't call normalize_email

[Django]

#26719: UserCreationForm doesn't call normalize_email
--+
 Reporter:  mitar |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by mitar):

 Yes, but you can extend it and add it to fields in Meta. It is a
 ModelForm. So the list of fields exposed is just a default.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.a0aa88b3dc177925b094de1e8de2f5a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17975: Make sessions more robust

[Django]

#17975: Make sessions more robust
--+
 Reporter:  PaulM |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by auvipy):

 * version:  1.4 => master


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.2d22ce1555c565032bb19ca49c8603dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26794: Migrating ForeignKey to OneToOneField creates extra index on PostgreSQL

[Django]

#26794: Migrating ForeignKey to OneToOneField creates extra index on PostgreSQL
+
 Reporter:  jdufresne   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Start with the models:

 {{{
 class A(models.Model):
 pass

 class B(models.Model):
 orig_onetoone = models.OneToOneField(A, on_delete=models.PROTECT,
 related_name='+')
 orig_fk = models.ForeignKey(A, on_delete=models.PROTECT,
 related_name='+')
 }}}

 Run `makemigrations`, then change `orig_fk` to a `OneToOneField`:

 {{{
 class A(models.Model):
 pass

 class B(models.Model):
 orig_onetoone = models.OneToOneField(A, on_delete=models.PROTECT,
 related_name='+')
 orig_fk = models.OneToOneField(A, on_delete=models.PROTECT,
 related_name='+')
 }}}

 Run `makemigrations` again.

 Now run `migrate` to create the database tables. The table created for
 model `B`:

 {{{
 \d testapp_b
   Table "public.testapp_b"
   Column  |  Type   |   Modifiers
 
--+-+
  id   | integer | not null default
 nextval('testapp_b_id_seq'::regclass)
  orig_fk_id   | integer | not null
  orig_onetoone_id | integer | not null
 Indexes:
 "testapp_b_pkey" PRIMARY KEY, btree (id)
 "testapp_b_orig_fk_id_68b3dcb4_uniq" UNIQUE CONSTRAINT, btree
 (orig_fk_id)
 "testapp_b_orig_onetoone_id_key" UNIQUE CONSTRAINT, btree
 (orig_onetoone_id)
 "testapp_b_ca8b5791" btree (orig_fk_id)
 Foreign-key constraints:
 "testapp_b_orig_fk_id_68b3dcb4_fk_testapp_a_id" FOREIGN KEY
 (orig_fk_id) REFERENCES testapp_a(id) DEFERRABLE INITIALLY DEFERRED
 "testapp_b_orig_onetoone_id_2353312c_fk_testapp_a_id" FOREIGN KEY
 (orig_onetoone_id) REFERENCES testapp_a(id) DEFERRABLE INITIALLY DEFERRED
 }}}

 Notice the column `orig_fk` has two indexes while the column
 `orig_onetoone` has only a single index.

 As these two columns are now described in the Python model identically, I
 expect them to have the same number of indexes.

 I created a test project with all the necessary migrations and models used
 to produce these results: https://github.com/jdufresne/djtest-fk-to-1to1

 Migrations:

 {{{
 0001

 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='A',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ],
 ),
 migrations.CreateModel(
 name='B',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('orig_fk',
 models.ForeignKey(on_delete=django.db.models.deletion.PROTECT,
 related_name='+', to='testapp.A')),
 ('orig_onetoone',
 models.OneToOneField(on_delete=django.db.models.deletion.PROTECT,
 related_name='+', to='testapp.A')),
 ],
 ),
 ]


 0002

 class Migration(migrations.Migration):

 dependencies = [
 ('testapp', '0001_initial'),
 ]

 operations = [
 migrations.AlterField(
 model_name='b',
 name='orig_fk',
 field=models.OneToOneField(on_delete=django.db.models.deletion.PROTECT,
 related_name='+', to='testapp.A'),
 ),
 ]
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.add9ba80a3002ae996aab1463617771e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26793: 1.10b1 affected with #22853

[Django]

#26793: 1.10b1 affected with #22853
-+
 Reporter:  strelnikov   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Migrations   |Version:  1.10
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 https://code.djangoproject.com/ticket/22853

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.7c1f848f30a0e6e08faeb5576760a910%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26792: cache.get_or_set() calculates the default key value in case it is already cached

[Django]

#26792: cache.get_or_set() calculates the default key value in case it is 
already
cached
-+-
 Reporter:  dvska|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dvska):

 * cc: d.v.selitsky@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.558de9f74f0943dcd0e44a9ba0017658%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26792: cache.get_or_set() calculates the default key value in case it is already cached

[Django]

#26792: cache.get_or_set() calculates the default key value in case it is 
already
cached
-+-
 Reporter:  dvska|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by dvska):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> The check "if default is None" causing an unconditional calculation of
> the default value.
>
> Behaviour before patch:
> {{{
> def heavy_routine_whose_result_to_be_cached():
> return todays_weather_forecast_calculated
>
> ...
> cache.set('todays_weather_forecast',
> heavy_routine_which_result_to_be_cached())
> ...
> val = cache.get_or_set('todays_weather_forecast',
> heavy_routine_which_result_to_be_cached())  ## calculates 2nd time, which
> is unwanted behaviour
> }}}
>
> Proposed patch -> https://github.com/django/django/pull/6824

New description:

 The check "if default is None" causing an unconditional calculation of the
 default value.

 Behaviour before patch:
 {{{
 def heavy_routine_whose_result_to_be_cached():
 return todays_weather_forecast_calculated

 ...
 cache.set('todays_weather_forecast',
 heavy_routine_whose_result_to_be_cached())
 ...
 val = cache.get_or_set('todays_weather_forecast',
 heavy_routine_which_result_to_be_cached())  ## calculates 2nd time, which
 is unwanted behaviour
 }}}

 Proposed patch -> https://github.com/django/django/pull/6824

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.fef55bd4411d697c31672c5c8a45625f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26792: cache.get_or_set() calculates the default key value in case it is already cached

[Django]

#26792: cache.get_or_set() calculates the default key value in case it is 
already
cached
-+
 Reporter:  dvska|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Cache system)  |Version:  1.9
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 The check "if default is None" causing an unconditional calculation of the
 default value.

 Behaviour before patch:
 {{{
 def heavy_routine_whose_result_to_be_cached():
 return todays_weather_forecast_calculated

 ...
 cache.set('todays_weather_forecast',
 heavy_routine_which_result_to_be_cached())
 ...
 val = cache.get_or_set('todays_weather_forecast',
 heavy_routine_which_result_to_be_cached())  ## calculates 2nd time, which
 is unwanted behaviour
 }}}

 Proposed patch -> https://github.com/django/django/pull/6824

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.14084da222fda6a91244d33b4c8a3f41%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11094: default_lon and default_lat have no effect for OSMGeoAdmin (was: OSMGeoAdmin not accepting default_lon and default_lat)

[Django]

#11094: default_lon and default_lat have no effect for OSMGeoAdmin
--+
 Reporter:  stuartk   |Owner:  stuartk
 Type:  Bug   |   Status:  new
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  OSMGeoAdmin, gis  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not too knowledgeable about GIS, so I can't comment on the appropriate
 solution.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.89e3831801035ead80e8a4ce51555e22%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26751: Make dbshell exit with the shell's error code

[Django]

#26751: Make dbshell exit with the shell's error code
-+-
 Reporter:  bersace  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.32ffc001b56723bc93c982b5bc58827d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26719: UserCreationForm doesn't call normalize_email

[Django]

#26719: UserCreationForm doesn't call normalize_email
--+
 Reporter:  mitar |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * component:  Forms => contrib.auth


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.3717d5cff2134fb40a80ca47643e2b52%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26719: UserCreationForm doesn't call normalize_email

[Django]

#26719: UserCreationForm doesn't call normalize_email
+
 Reporter:  mitar   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.10
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by timgraham):

 Not sure I understand the premise of the report because `UserCreationForm`
 only has `fields = ("username",)` (no `email` field).

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c7646dd0f1712681024e1cc7dc938dd4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17209: Dogfood class-based views in contrib.auth

[Django]

#17209: Dogfood class-based views in contrib.auth
-+-
 Reporter:  melinath |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  class-based views| Triage Stage:  Ready for
  admin auth |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  auvipy =>
 * status:  assigned => new
 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0b3978ad5f83b9a5725928809c099b85%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24359: "Http exceptions are provided in django.http" links to a page that does not list or link to HTTP exceptions

[Django]

#24359: "Http exceptions are provided in django.http" links to a page that does 
not
list or link to HTTP exceptions
---+-
 Reporter:  pydanny|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8alpha1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by timgraham):

 New ticket please.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.de1516cc7646bb6e6341fa09a09e5a10%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24359: "Http exceptions are provided in django.http" links to a page that does not list or link to HTTP exceptions

[Django]

#24359: "Http exceptions are provided in django.http" links to a page that does 
not
list or link to HTTP exceptions
---+-
 Reporter:  pydanny|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.8alpha1
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by asfaltboy):

 I have [https://github.com/spookylukey/django-paypal/issues/79 a use case
 for adding RawPostDataException] . I feel it would have helped me greatly
 if Django had
 
[https://github.com/django/django/blob/46338296aa292aa31e329559c561a010a197c2aa/django/http/request.py#L35-L39
 this docstring] in the
 [https://docs.djangoproject.com/en/1.8/ref/exceptions/#http-exceptions
 Http Exceptions documenation] (or even a mention in the
 [https://docs.djangoproject.com/en/1.9/ref/request-
 response/#django.http.HttpRequest HttpRequest docs]).

 Shall I open a new ticket or can we add a patch here?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.61cfbfdc5d7a0f541e2572bfcac46bf4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26688: Inconsistent logging of 5xx and 4xx requests to django.request

[Django]

#26688: Inconsistent logging of 5xx and 4xx requests to django.request
---+
 Reporter:  solarissmoke   |Owner:  seocam
 Type:  Bug|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 Patch needs a rebase and I left some additional comments for improvement.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.7334b21b55cd3ad75960d7cfba86cc70%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26791: Replace LiveServerTestCase port ranges with binding to port 0

[Django]

#26791: Replace LiveServerTestCase port ranges with binding to port 0
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6791 PR]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.15433841ea1c6abd114768625e19bce1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26791: Replace LiveServerTestCase port ranges with binding to port 0

[Django]

#26791: Replace LiveServerTestCase port ranges with binding to port 0
+
   Reporter:  timgraham |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Donald pointed out https://www.dnorth.net/2012/03/17/the-port-0-trick/ and
 suggested that Django might be able to take advantage of that technique.

 [https://groups.google.com/d/topic/django-
 developers/_TD8IkSLgqE/discussion django-developers thread]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.7a0a55665cb6c5450815a6050713da8c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19544: IntegrityError during Many To Many add()

[Django]

#19544: IntegrityError during Many To Many add()
-+-
 Reporter:  Kronuz   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by guettli):

 This StackO question tries to find a work around:
 http://stackoverflow.com/questions/37654072/django-integrityerror-during-
 many-to-many-add/37968648

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a839414dc2f55982d588d0392b623916%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26790: Move BaseUserManager.normalize_email() to AbstractUser (was: Consistency in normalize_email and normalize_username)

[Django]

#26790: Move BaseUserManager.normalize_email() to AbstractUser
--+
 Reporter:  tam0407   |Owner:  tam0407
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  normalize_email   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * version:  1.10 => master
 * stage:  Unreviewed => Accepted


Comment:

 If the user has overridden `BaseUserManager.normalize_email()`, we need to
 use that implementation during the deprecation period. The idea is similar
 to the deprecation of `ModelAdmin.declared_fieldsets` in
 ebb3e50243448545c7314a1932a9067ddca5960b.

 It seems to me the `normalize_email()` should be moved to `AbstractUser`
 (which has the `email` field) rather than `AbstractBaseUser`.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a1a3cc75043d7771e701f204d2bc59ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26788: update of geometry field from the another one crashes

[Django]

#26788: update of geometry field from the another one crashes
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.dce0bef116738b32e1582f5533e870f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26789: ORM produces query with NULL instead of empty geometry

[Django]

#26789: ORM produces query with NULL instead of empty geometry
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8b387c7fbf365b25a9149b04a0b9a270%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25218: python_2_unicode_compatible causes infinite recursion when super().__str__() is called

[Django]

#25218: python_2_unicode_compatible causes infinite recursion when
super().__str__() is called
---+--
 Reporter:  jscn   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Utilities  |  Version:  1.8
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by TZanke):

 * cc: tzanke@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.695a629acedd4c334a82382bdb9662b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #12651: AutoSlugField, that can recreate unique slugs during saving.

[Django]

#12651: AutoSlugField, that can recreate unique slugs during saving.
-+-
 Reporter:  Ciantic  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by fmalina):

 Just to revive this ticket. Here's an example implementation I find quite
 acceptable in user code:

 {{{#!python
 class Article(models.Model):
 title = models.CharField(max_length=128)
 slug = models.SlugField(max_length=130)
 # ...

 def save(self, *args, **kwargs):
 if not len(self.slug.strip()):
 self.slug = slugify(self.title)

 _slug = self.slug
 _count = 1

 while True:
 try:
 Article.objects.all().exclude(pk=self.pk).get(slug=_slug)
 except MultipleObjectsReturned:
 pass
 except ObjectDoesNotExist:
 break
 _slug = "%s-%s" % (self.slug, _count)
 _count += 1

 self.slug = _slug

 super(Article, self).save(*args, **kwargs)
 }}}

 I've also used a regex based alternative implementation:

 {{{#!python
 import re

 class Article(models.Model):
 ...
 def get_slug(self):
  return '%s-%s' % (slugify(self.this), slugify(self.that))

 def check_slug(self, slug):
 # ensure uniqueness
 while(Article.objects.filter(slug__iexact=slug).count()):  # if
 not unique
 suff = re.search("\d+$", slug)  # get the current number
 suffix if present
 suff = suff and suff.group() or 0
 next = str(int(suff) +1)  # increment it & turn to string for
 re.sub
 slug = re.sub("(\d+)?$", next, slug)  # replace with higher
 suffix, retry
 return slug

 def save(self, *args, **kwargs):
 #...
 slug = self.get_slug()
 if not self.pk or (self.pk and not slug in self.slug):
 self.slug = self.check_slug(slug)
 super( ...
 }}}


 Could this be implemented by adding a pre_save method to the SlugField?
 
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2073

 Maybe call it add_auto_increment=True.

 Any ideas on how this could actually look in the core, as opposed to just
 user code?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.02e0d9e46776a048402546b675b93454%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26790: Consistency in normalize_email and normalize_username

[Django]

#26790: Consistency in normalize_email and normalize_username
-+-
 Reporter:  tam0407  |Owner:  tam0407
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  normalize_email  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tam0407):

 * status:  new => assigned
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.7f03efb2934f24201e5daa340c8eafd7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26790: Consistency in normalize_email and normalize_username

[Django]

#26790: Consistency in normalize_email and normalize_username
--+-
 Reporter:  tam0407   |  Owner:  tam0407
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.auth  |Version:  1.10
 Severity:  Normal|   Keywords:  normalize_email
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 In the current code, `normalize_username` is placed in `AbstractBaseUser`,
 but `normalize_email` currently stay in `BaseUserManager` for backward-
 combatibility.
 I suggest we move `normalize_email` logic to `AbstractBaseUser` for
 consistency with `normalize_username`, and raise warning for the original
 one.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.b0a66b0dbdb9b4421df2e209e8e523d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.