Re: [Django] #21196: Warning when running the test suite under MySQL

[Django]

#21196: Warning when running the test suite under MySQL
---+-
 Reporter:  aaugustin  |Owner:  tchaumeny
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  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
---+-

Comment (by loic):

 Indeed:
 Prefix support and lengths of prefixes (where supported) are storage
 engine dependent. For example, a prefix can be up to 1000 bytes long for
 MyISAM tables, and 767 bytes for InnoDB tables.

--
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.2ab4df6f26d717375b81c77e276a481b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23684: ImageField HINT mentions wrong pip package name

[Django]

#23684: ImageField HINT mentions wrong pip package name
-+-
 Reporter:  nicholasserra|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by nicholasserra):

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


Comment:

 Github PR: https://github.com/django/django/pull/3389

--
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/071.4672a703b05eaaa21348491874b499dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23684: ImageField HINT mentions wrong pip package name

[Django]

#23684: ImageField HINT mentions wrong pip package name
--+
 Reporter:  nicholasserra |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 If you use an ImageField without installing the Pillow package, a field
 hint mentions that you should "pip install pillow". The correct package
 name is "Pillow" with an uppercase P.

--
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/056.3b96a9037b9260a0a7832fa8cbb6c908%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21196: Warning when running the test suite under MySQL

[Django]

#21196: Warning when running the test suite under MySQL
---+-
 Reporter:  aaugustin  |Owner:  tchaumeny
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  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 tchaumeny):

 * owner:  nobody => tchaumeny
 * cc: t.chaumeny@… (added)
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 I encountered the same problem when trying to run the test suite under
 MySQL. It looks like MySQL doesn't support indexing VARCHAR fields with a
 length of 767+ on InnoDB tables (see
 http://dev.mysql.com/doc/refman/5.1/en/create-index.html). #15938
 introduced a `SlugField` on a field with `max_length = 1000` for a test.

 https://github.com/django/django/pull/3388 sets `db_index=False`, which
 solves the problem.

--
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.016920bcab9d3be23c503c8708a65ce0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23546: callproc **kwargs or *args parameter

[Django]

#23546: callproc **kwargs or *args parameter
-+-
 Reporter:  fatal10110   |Owner:
 Type:  New feature  |  averybigant
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by shaib):

 I've added some Notes on the PR, and opened a related
 [https://groups.google.com/d/msg/django-
 developers/v3AhQhJFhGM/TScISVjLBQoJ mailing list discussion].

--
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.08d3e185c19272c390ebfa567b29bfe3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23649: Oracle GIS testing -- fails to destroy old leftover test database after unclean ending

[Django]

#23649: Oracle GIS testing -- fails to destroy old leftover test database after
unclean ending
-+-
 Reporter:  shaib|Owner:  shaib
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  oracle testing   |  Needs documentation:  0
  geodjango gis  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by shaib):

 Thanks, Tim, for adding the release notes I neglected.

--
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.18421b1e27fae0100aa4d5f8f59e4b61%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23680: DecimalField and Postgres ORM produces incorrect SQL on filter comparison

[Django]

#23680: DecimalField and Postgres ORM produces incorrect SQL on filter 
comparison
-+-
 Reporter:  bufke|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shaib):

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


Comment:

 {{{#!python
 >>> from decimal import Decimal as D
 >>> D(59.99)
 Decimal('59.99198951966012828052043914794921875')
 >>> D('59.99')
 Decimal('59.99')
 >>>
 }}}

 I don't think there's anything wrong with the ORM here. Your problem is
 that 59.99 cannot be represented as a float. Feel free to reopen if you
 have a justification.

--
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.c77a5ea75eb81172c67246b24641dd38%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23683: CharField's max_length is Incorrectly Listed as Optional in Documentation

[Django]

#23683: CharField's max_length is Incorrectly Listed as Optional in 
Documentation
---+--
 Reporter:  machineghost   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.7
 Severity:  Normal |   Resolution:  invalid
 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 claudep):

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


Comment:

 You are mixing the form field documentation with the model field
 documentation:
 https://docs.djangoproject.com/en/dev/ref/forms/fields/#charfield
 https://docs.djangoproject.com/en/dev/ref/models/fields/#charfield

--
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.78b508e6c298a198fa52d10c51c84f3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23321: Remove .mo files from the Django Git repository

[Django]

#23321: Remove .mo files from the Django Git repository
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Internationalization  |  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
--+

Comment (by claudep):

 Here's a branch where I started working on this:
 https://github.com/claudep/django/tree/23321

--
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.fcadc815a3b128304f79052b79d164a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23683: CharField's max_length is Incorrectly Listed as Optional in Documentation

[Django]

#23683: CharField's max_length is Incorrectly Listed as Optional in 
Documentation
---+
 Reporter:  machineghost   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The documentation (for all currently documented versions of Django) on the
 CharField class states that it:

 {{{
 Has two optional arguments for validation:

 max_length
 min_length
 }}}

 However, if you actually try to create a CharField without a max_length
 Django will complain:

 {{{
 "some_field": CharFields require a "max_length" attribute that is a
 positive integer.
 }}}


 So, it seems that the max_length arg is required by Django, but listed as
 optional in the documentation, and thus it appears the documentation
 requires an update.

--
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/055.3804868213bbe7098e803973b2d5cecf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21644: FormWizard needs confirmation step logic

[Django]

#21644: FormWizard needs confirmation step logic
---+
 Reporter:  nickname123|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.formtools  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 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 gchp):

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


Comment:

 formtools has been extracted into its own repository
 (​https://github.com/django/django-formtools/). Because of this, the issue
 tracking for this package has been moved to GitHub issues. I'm going to
 close this ticket, but I've created a GitHub issue to replace it where the
 conversation can continue: ​https://github.com/django/django-
 formtools/issues/17. Thanks!

--
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/069.8902d3edd6bd5daa185ce90645d4cbd0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21667: Allow dynamic form classes with WizardView

[Django]

#21667: Allow dynamic form classes with WizardView
---+
 Reporter:  nickname123|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.formtools  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 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 gchp):

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


Comment:

 formtools has been extracted into its own repository
 (​https://github.com/django/django-formtools/). Because of this, the issue
 tracking for this package has been moved to GitHub issues. I'm going to
 close this ticket, but I've created a GitHub issue to replace it where the
 conversation can continue: ​https://github.com/django/django-
 formtools/issues/16. Thanks!

--
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/069.2c4b4c594fd839d541da54fcdd5ae865%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22800: FormWizards leak data into other forms.

[Django]

#22800: FormWizards leak data into other forms.
---+
 Reporter:  danielsamuels  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.formtools  |  Version:  1.6
 Severity:  Normal |   Resolution:  fixed
 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 gchp):

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


Comment:

 formtools has been extracted into its own repository
 (https://github.com/django/django-formtools/). Because of this, the issue
 tracking for this package has been moved to GitHub issues. I'm going to
 close this ticket, but I've created a GitHub issue to replace it where the
 conversation can continue: https://github.com/django/django-
 formtools/issues/15. Thanks!

--
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/071.ee097e91e85e6132a2b644bdf97480b2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23678: Database default not removed if default=None

[Django]

#23678: Database default not removed if default=None
-+
 Reporter:  timgraham|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by loic):

 @paulcdejean how do you get those results? I just tried with the
 `sqlmigrate` command on initial migration on MySQL and my
 `models.CharField(max_length=42, null=True)` doesn't show 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/067.ae703bb004eae27155a0a2c45cd0a394%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23299: Add some interoperability to _() function calls parsing in templatize function.

[Django]

#23299: Add some interoperability to _() function calls parsing in templatize
function.
--+
 Reporter:  niwibe|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  template-refactor | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 I believe this is a duplicate of #12377 which was closed as wontfix long
 ago.

 But we're going to need this as part of my plan to support multiple
 template engines.

--
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.b6d720658e1c0318abcdcc24d5b37452%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23468: fixtures are imported twice with duplicate FIXTURE_DIRS

[Django]

#23468: fixtures are imported twice with duplicate FIXTURE_DIRS
-+-
 Reporter:  karyon   |Owner:  kswiat
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.6
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 Wouldn't it be better to check this in the loaddata `fixture_dirs` method?

--
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.4595581c1a6a1222fc9ccfc11e9e60ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23682: Stronger redirect loop detection in the test client

[Django]

#23682: Stronger redirect loop detection in the test client
---+--
 Reporter:  wrwrwr |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  Version:  master
 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 wrwrwr):

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


Comment:

 [https://github.com/wrwrwr/django/compare/ticket_23682 Proposed changes]:
 * defined a new `CircularRedirectError`;
 * changed the loop detection to throw the exception on repeated URLs and
 chains longer than 20;
 * added a "redirect to self" test with a changing query argument.

 Could all the loop prevention tests maybe live in `test_client` rather
 than `test_client_regress`?

--
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.fa965783549b8d382753e3c8fd4f8547%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23681: NullBooleanSelect should have choices kwarg (was: NullBooleanSelect should have empty_label or similar)

[Django]

#23681: NullBooleanSelect should have choices kwarg
-+--
 Reporter:  benjaoming   |Owner:  benjaoming
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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 benjaoming):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => benjaoming
 * needs_docs:   => 0


Old description:

> `NullBooleanSelect` is responsible of making the values 1, 2, and 3 turn
> into None, True or False. That's why having custom "choices" kwarg is
> perhaps a bit over the top. Well, it's pretty meaningless to have a
> utility class if you start passing a choices kwarg that contains half of
> the code that makes up NullBooleanSelect.
>
> However, I need one small feature from this widget! Namely, that the
> following...
>

> {{{
> class NullBooleanSelect(Select):
> """
> A Select Widget intended to be used with NullBooleanField.
> """
> def __init__(self, attrs=None):
> choices = (('1', ugettext_lazy('Unknown')),
>('2', ugettext_lazy('Yes')),
>('3', ugettext_lazy('No')))
> super(NullBooleanSelect, self).__init__(attrs, choices)
> }}}
>

> ...is changed to:
>

> {{{
> class NullBooleanSelect(Select):
> """
> A Select Widget intended to be used with NullBooleanField.
> """
> def __init__(self, empty_label=None, attrs=None):
> choices = (('1', empty_label or ugettext_lazy('Unknown')),
>('2', ugettext_lazy('Yes')),
>('3', ugettext_lazy('No')))
> super(NullBooleanSelect, self).__init__(attrs, choices)
> }}}
>

> The motivation is that I often leave out labels to have them put as the
> default first option of the Select. An example use:
>

> {{{
> class MyForm(forms.Form):
> has_payments = forms.NullBooleanField(
> label="",
> required=False,
> widget=NullBooleanSelect(empty_label=_(u"Has previous
> payments?"))
> help_text=_(u"Only show subscriptions that have previously been
> charged"),
> )
>
> }}}
>
> Even more preferable, would be to place the `empty_label` kwarg in
> `NullBooleanField`, as that would match the options for ModelChoiceField.

New description:

 `NullBooleanSelect` is responsible of making the values 1, 2, and 3 turn
 into None, True or False. That's very nice of it, however it does not
 allow to customize the texts of the choices.

 I'm not sure if exposing the internal 1, 2, 3 representation is a good
 idea, but it would seem okay since it follows the convention of other
 Select widgets. Ideally, I would like to see this...


 {{{
 class NullBooleanSelect(Select):
 """
 A Select Widget intended to be used with NullBooleanField.
 """
 def __init__(self, attrs=None):
 choices = (('1', ugettext_lazy('Unknown')),
('2', ugettext_lazy('Yes')),
('3', ugettext_lazy('No')))
 super(NullBooleanSelect, self).__init__(attrs, choices)
 }}}


 ...changed to:


 {{{
 class NullBooleanSelect(Select):
 """
 A Select Widget intended to be used with NullBooleanField.
 """
 def __init__(self, choices=None, attrs=None):
 if not choices:
 choices = (('1', empty_label or ugettext_lazy('Unknown')),
('2', ugettext_lazy('Yes')),
('3', ugettext_lazy('No')))
 super(NullBooleanSelect, self).__init__(attrs, choices)
 }}}


 The motivation is that I often leave out labels to have them put as the
 default first option of the Select. An example use:

 {{{
 class MyForm(forms.Form):
 gender = forms.NullBooleanField(
 label="",
 required=False,
 widget=NullBooleanSelect(choices=[("1", "Male and female"),
   ("2", "Only female"),
   ("3", "Only Male")])
 help_text=_(u"Only show subscriptions that have previously been
 charged"),
 )

 }}}

 Even more preferable, would be to place the `choices` kwarg in
 `NullBooleanField`, as that would match the options for ChoiceField.

 Updated In the original issue report, I put `empty_label` but
 realized that when selecting "Yes", it was impossible for the user to see
 what "Yes" was the answer to.

--

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

[Django] #23682: Stronger redirect loop detection in the test client

[Django]

#23682: Stronger redirect loop detection in the test client
---+
 Reporter:  wrwrwr |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The test client has a mechanism to detect circular redirects. I'd like to
 propose two changes to it;
 * when a loop is detected, throw an exception rather than break silently;
 * detect and complain about very (possibly infinitely) long redirect
 chains with differing URLs (at least when they only differ by a view
 argument value or query string).

 [https://github.com/wrwrwr/django/compare/dropped/redirect-with-view-name-
 loops A few tests] that are not part of the proposed changes, but
 demonstrate how one could try to test for loops (currently 3 of these just
 past, while a browser would run into a loop, and 2 actually loop
 indefinitely).

--
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/049.9ed867716e608272e023d2db1f672390%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23679: varchar(255) converted into varchar(255) NOT NULL after inspectdb followed by migrate

[Django]

#23679: varchar(255) converted into varchar(255) NOT NULL after inspectdb 
followed
by migrate
-+-
 Reporter:  paulcdejean  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.7
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 inspectdb output has to be reviewed in all cases. For me, the choice is:

 * keep the current output and add a comment like: `# Field was detected as
 NULL, but we didn't add null=True, see
 https://docs.djangoproject.com/en/stable/ref/models/fields/#null`

 * change the output to let `null=True` and add the comment: `# Read
 https://docs.djangoproject.com/en/stable/ref/models/fields/#null and
 consider removing null=True`

 I'm currently favoring the second option.

--
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/069.f87044f0636b22c2f2000c0a010d3e6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23681: NullBooleanSelect should have empty_label or similar

[Django]

#23681: NullBooleanSelect should have empty_label or similar
-+
 Reporter:  benjaoming   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 `NullBooleanSelect` is responsible of making the values 1, 2, and 3 turn
 into None, True or False. That's why having custom "choices" kwarg is
 perhaps a bit over the top. Well, it's pretty meaningless to have a
 utility class if you start passing a choices kwarg that contains half of
 the code that makes up NullBooleanSelect.

 However, I need one small feature from this widget! Namely, that the
 following...


 {{{
 class NullBooleanSelect(Select):
 """
 A Select Widget intended to be used with NullBooleanField.
 """
 def __init__(self, attrs=None):
 choices = (('1', ugettext_lazy('Unknown')),
('2', ugettext_lazy('Yes')),
('3', ugettext_lazy('No')))
 super(NullBooleanSelect, self).__init__(attrs, choices)
 }}}


 ...is changed to:


 {{{
 class NullBooleanSelect(Select):
 """
 A Select Widget intended to be used with NullBooleanField.
 """
 def __init__(self, empty_label=None, attrs=None):
 choices = (('1', empty_label or ugettext_lazy('Unknown')),
('2', ugettext_lazy('Yes')),
('3', ugettext_lazy('No')))
 super(NullBooleanSelect, self).__init__(attrs, choices)
 }}}


 The motivation is that I often leave out labels to have them put as the
 default first option of the Select. An example use:


 {{{
 class MyForm(forms.Form):
 has_payments = forms.NullBooleanField(
 label="",
 required=False,
 widget=NullBooleanSelect(empty_label=_(u"Has previous payments?"))
 help_text=_(u"Only show subscriptions that have previously been
 charged"),
 )

 }}}

 Even more preferable, would be to place the `empty_label` kwarg in
 `NullBooleanField`, as that would match the options for ModelChoiceField.

--
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.f9afd42766958380859082eddb4789bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23679: varchar(255) converted into varchar(255) NOT NULL after inspectdb followed by migrate

[Django]

#23679: varchar(255) converted into varchar(255) NOT NULL after inspectdb 
followed
by migrate
-+-
 Reporter:  paulcdejean  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.7
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by paulcdejean):

 How about adding a command line option to inspectdb so the user can
 choose. Good practice being enforced can be the default but users who need
 to deviate for some reason can do so without having to hack the inspectdb
 source as I did.

--
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/069.a3699ba4dd02304a5d688046e6a2cfd1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23646: query set sql update to change different values by different keys

[Django]

#23646: query set sql update to change different values by different keys
-+-
 Reporter:  brillgen |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shaib):

 On an old project, ~10 years ago and not Django based, we used a "bulk
 update" procedure that did:

 1) Bulk-insert the new records into a temporary table
 2) update in one statement using a join (SQL Server lets you do that)

 On hundreds of records, this was significantly faster than updating one-
 by-one (I no longer have access to any hard data, and it's irrelevant
 anyways).

 Anyway, I suspect a better API would involve passing a collection of
 objects and selecting just the fields to update:
 `Book.objects.update_many(books, 'price')`

--
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.f774a0bce4298cd7eb4ac171bd7c060e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15184: Error when subclassing models.ForeignKey field

[Django]

#15184: Error when subclassing models.ForeignKey field
-+-
 Reporter:  rupa108  |Owner:
 Type:  Bug  |  furious_luke
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey, models,  | Triage Stage:  Accepted
  subclassing|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timgraham):

 `SubfieldBase` has been
 [https://docs.djangoproject.com/en/dev/releases/1.8/#subfieldbase
 deprecated in Django 1.8]. Can the issue be reproduced without it? If so,
 please update the patch, thanks. If not, we should close this ticket.

--
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.2a95cd54379a7c19435b20a94f80ccf7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23676: FileField documentation is confusing about database column representation

[Django]

#23676: FileField documentation is confusing about database column 
representation
--+
 Reporter:  jdufresne |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"c1b9f99a812d01124ba4ddefcafaa90dcb5b05ae"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c1b9f99a812d01124ba4ddefcafaa90dcb5b05ae"
 Fixed #23676 -- Rearranged sentence; "by default" applies only to max
 length
 }}}

--
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.6ff142ad96a9502d39cfa9bcce8b3605%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23676: FileField documentation is confusing about database column representation

[Django]

#23676: FileField documentation is confusing about database column 
representation
--+
 Reporter:  jdufresne |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"7d90fed1a073318defbb7cf80015530a38a09bbc"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d90fed1a073318defbb7cf80015530a38a09bbc"
 [1.6.x] Fixed #23676 -- Rearranged sentence; "by default" applies only to
 max length

 Backport of c1b9f99a81 from 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/067.6cdf481b8f3af1adc18027801f2f5484%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23676: FileField documentation is confusing about database column representation

[Django]

#23676: FileField documentation is confusing about database column 
representation
--+
 Reporter:  jdufresne |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"37ab955d69ea541b4c66e225cc24dc0a2ee057be"]:
 {{{
 #!CommitTicketReference repository=""
 revision="37ab955d69ea541b4c66e225cc24dc0a2ee057be"
 [1.7.x] Fixed #23676 -- Rearranged sentence; "by default" applies only to
 max length

 Backport of c1b9f99a81 from 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/067.79903f9fd526cbbf133f338cb381284c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23583: makemessages for javascript no longer works

[Django]

#23583: makemessages for javascript no longer works
--+
 Reporter:  nijel |Owner:  claudep
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  1.7
 Severity:  Release blocker   |   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 claudep):

 * needs_better_patch:  1 => 0


Comment:

 Alternative patch: https://github.com/django/django/pull/3386
 Review welcome (possibly on Windows). This is a candidate for 1.7.1.

--
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.55d6082a0434504339878306200e303d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23583: makemessages for javascript no longer works

[Django]

#23583: makemessages for javascript no longer works
--+
 Reporter:  nijel |Owner:  claudep
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  1.7
 Severity:  Release blocker   |   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 claudep):

 * status:  new => assigned
 * severity:  Normal => Release blocker
 * needs_better_patch:  0 => 1
 * component:  Translations => Internationalization
 * owner:  nobody => claudep
 * has_patch:  0 => 1
 * 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/063.a732093acb85417e396b3c384253b760%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23679: varchar(255) converted into varchar(255) NOT NULL after inspectdb followed by migrate

[Django]

#23679: varchar(255) converted into varchar(255) NOT NULL after inspectdb 
followed
by migrate
-+-
 Reporter:  paulcdejean  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.7
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 The fact that `inspectdb` doesn't add `null=True` on
 `CharField`s/`TextField`s is based on a Django "good practice", explained
 in https://docs.djangoproject.com/en/stable/ref/models/fields/#null

 Now the question is, should `inspectdb` reflect the current database
 structure as faithfully as possible, or should it entice users to follow
 good practices? At a minimum, Django should add a comment that it has not
 respected the NULL flag on the introspected field. Accepted the ticket on
 that base.

--
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/069.37fb9e1f9fea473a9128b07d334a613f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.