date:20171116

Re: [Django] #28810: Use the Python 3-esque str.format logging formatting style over '%'

2017-11-16 Thread Django

#28810: Use the Python 3-esque str.format logging formatting style over '%'
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 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
-+-

Comment (by Chris Lamb):

 PR https://github.com/django/django/pull/9359

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

[Django] #28810: Use the Python 3-esque str.format logging formatting style over '%'

2017-11-16 Thread Django

#28810: Use the Python 3-esque str.format logging formatting style over '%'
+
   Reporter:  Chris Lamb|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  1.11
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 We currently use the ``%(foo)s`` style in Django and in docs.  This
 "smells" quite Python 2.x when there is a ``str.format`` variety that
 uses, eg. ``{foo}``.

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

[Django] #28809: Changing SRID on geometry field doesn't create working migration

2017-11-16 Thread Django

#28809: Changing SRID on geometry field doesn't create working migration
-+-
   Reporter:  Jani   |  Owner:  nobody
  Tiainen|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  migrations gis
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When changing SRID of geometry field:

 before:
 {{{#!python
 class AddressLog(models.Model):
 location = models.PointField(blank=True, null=True, srid=4326)
 }}}

 after:
 {{{#!python
 class AddressLog(models.Model):
 location = models.PointField(blank=True, null=True, srid=3067)
 }}}

 Migration:
 {{{#!python
 class Migration(migrations.Migration):

 dependencies = [
 ('myapp', '0002_auto_20171114_1021'),
 ]

 operations = [
 migrations.AlterField(
 model_name='addresslog',
 name='location',
 field=django.contrib.gis.db.models.fields.PointField(blank=True,
 null=True, srid=3067),
 ),
 ]
 }}}

 Traceback:
 {{{#!python
 (myapp) jtiai@jns42-l:~/projects/myproject (default) $ ./manage.py migrate
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, sessions, myapp
 Running migrations:
   Applying myapp.0003_auto_20171117_0641...Traceback (most recent call
 last):
   File "./manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 364, in
 execute_from_command_line
 utility.execute()
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 356, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/core/management/base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/core/management/base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/core/management/commands/migrate.py", line 204, in handle
 fake_initial=fake_initial,
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 115, in migrate
 state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
 fake_initial=fake_initial)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 145, in
 _migrate_all_forwards
 state = self.apply_migration(state, migration, fake=fake,
 fake_initial=fake_initial)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/db/migrations/executor.py", line 244, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/db/migrations/migration.py", line 129, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/db/migrations/operations/fields.py", line 216, in
 database_forwards
 schema_editor.alter_field(from_model, from_field, to_field)
   File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-
 packages/django/db/backends/base/schema.py", line 494, in alter_field
 (old_field, new_field),
 ValueError: Cannot alter field myapp.AddressLog.location into
 myapp.AddressLog.location - they do not properly define db_type (are you
 using a badly-written custom field?)
 }}}


 Using Spatialite as backend engine.

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

Re: [Django] #28808: Allow customizing the fallback language

2017-11-16 Thread Django

#28808: Allow customizing the fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  Claude
 |  Paroz
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Denis Anuschewski):

 My pull request [https://github.com/django/django/pull/9248] implements
 this feature by introducing a new setting `LANGUAGE_FALLBACK`. When
 untouched it doesn't change the default translation routine, but by
 setting your desired language here you can control the translation
 fallback.

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

Re: [Django] #28757: Allow using forms of contrib.auth without installing contrib.auth

2017-11-16 Thread Django

#28757: Allow using forms of contrib.auth without installing contrib.auth
-+-
 Reporter:  Sagar Chalise|Owner:  hui shang
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  auth forms apps  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by hui shang):

 * has_patch:  0 => 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/070.e5d737aa108bbd6564c6a99d71dfe179%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28600: Add prefetch related support to RawQuerySet

2017-11-16 Thread Django

#28600: Add prefetch related support to RawQuerySet
-+-
 Reporter:  Adnan Umer   |Owner:  Adnan
 |  Umer
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by Asif Saifuddin Auvi):

 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 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/064.585b583302e9220a5f45768d958b001e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28808: Allow customizing the fallback language

2017-11-16 Thread Django

#28808: Allow customizing the fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  Claude
 |  Paroz
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Denis Anuschewski):

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

Re: [Django] #28808: Allow customizing the fallback language

2017-11-16 Thread Django

#28808: Allow customizing the fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  Claude
 |  Paroz
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:
  internationalization, request  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Denis Anuschewski):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 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/066.9f9cc5ebd390c4bef3c28b9a46c0821b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28808: Allow customizing the fallback language

2017-11-16 Thread Django

#28808: Allow customizing the fallback language
-+-
Reporter: Denis | Owner: Claude Paroz
Anuschewski|
Type: New| Status: assigned
feature|
Component: |Version: 1.11
Internationalization | Keywords: translation,
Severity: Normal | internationalization, request
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
This is a follow-up ticket for #28636, where I proposed changes that
differ from the much better solution which came up in the analysis from
Claude Paroz. So in order to clean up things the new approach with the
underlying problem is now mentioned here:

Currently there is no way to explicitly specify a fallback language for
both unsupported languages ( = not in `settings.LANGUAGES`) and missing
literal translations in the translation files. This job is done by
`settings.LANGUAGE_CODE` which controls a lot of other language-related
features.

It would be useful to be able to control this behavior without touching
`settings.LANGUAGE_CODE` which defines your project's installation-wide
language preference. One scenario in which you would benefit from that is
having a non-English project where you want to deliver English as fallback
for languages that differ from your base language.

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

Re: [Django] #28636: Allow customizing the fallback language from the locale middleware (was: Allow customizing the translation fallback language)

2017-11-16 Thread Django

#28636: Allow customizing the fallback language from the locale middleware
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  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/066.5d4c3b8a866c9db18a641229ef6ccea2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27629: Inconsistent check of allow_relation in ForwardManyToOneDescriptor.set

2017-11-16 Thread Django

#27629: Inconsistent check of allow_relation in 
ForwardManyToOneDescriptor.__set__
-+-
 Reporter:  Sven Coenye  |Owner:  Stefan R.
 |  Filipek
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  allow_relation   | Triage Stage:  Accepted
  ForwardManyToOneDescriptor |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stefan R. Filipek):

 * owner:  nobody => Stefan R. Filipek
 * status:  new => assigned


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

Re: [Django] #28807: No error emails sent to admin list

2017-11-16 Thread Django

#28807: No error emails sent to admin list
-+-
 Reporter:  Gary Greyling|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  settings, 500| Triage Stage:
  error, email   |  Unreviewed
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:   => needsinfo


Comment:

 You will need to debug your application and explain why Django is at
 fault, or at least provide a sample project that we can use to reproduce
 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.c16245f4129b3dfe7972863d9e48a31e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27629: Inconsistent check of allow_relation in ForwardManyToOneDescriptor.set

2017-11-16 Thread Django

Comment (by Stefan R. Filipek):

I'm running into this issue as well on 1.11.7 and the latest master
branch. There's a large amount of inconsistency with this behavior that
I've run into.

General constructors, create(), get_or_create() and update_or_create()
don't call allow_relation(). Assignment of a foreign key will perform the
check, only once the object has been saved.

I've been working of a fix, but it's starting to require significant
modifications.

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

[Django] #28807: No error emails sent to admin list

2017-11-16 Thread Django

#28807: No error emails sent to admin list
-+-
   Reporter:  Gary   |  Owner:  nobody
  Greyling   |
   Type:  Bug| Status:  new
  Component:  Core   |Version:  1.11
  (Mail) |   Keywords:  settings, 500
   Severity:  Normal |  error, email
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 After updating to 1.11 emails to admins on error no longer get sent. Using
 the command line ./manager.py senttestemail --admin however works.

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Lamb):

 Cool, so in summary, we have three paths forward:

 a) Remove the unused ``_REV``
 b) Complete the set.
 c) No action.

 You seem to be in favour of "a", I'm leaning towards "b". I'm easy with
 either - let me know which you would like and I'll go ahead and update the
 PR/whatever. :)

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

Re: [Django] #28805: Provide a new database function for RegexpReplace

2017-11-16 Thread Django

#28805: Provide a new database function for RegexpReplace
-+-
 Reporter:  Joey Wilhelm |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Joey Wilhelm):

 Yeah, I was debating the thought of creating some sort of `django-
 postgres-regex` package, for this and related functions. But if I could
 contribute it to core, why not, ya know?

 The implementation relatively easy; I based it off, I believe, Substr.

 {{{#!python
 from django.db.models import Func, Value


 class RegexpReplace(Func):
 function = 'REGEXP_REPLACE'

 def __init__(self, expression, pattern, replacement, **extra):
 if not hasattr(pattern, 'resolve_expression'):
 if not isinstance(pattern, str):
 raise TypeError("'pattern' must be a string")
 pattern = Value(pattern)
 if not hasattr(replacement, 'resolve_expression'):
 if not isinstance(replacement, str):
 raise TypeError("'replacement' must be a string")
 replacement = Value(replacement)
 expressions = [expression, pattern, replacement]
 super().__init__(*expressions, **extra)
 }}}

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

Re: [Django] #28805: Provide a new database function for RegexpReplace

2017-11-16 Thread Django

#28805: Provide a new database function for RegexpReplace
-+-
 Reporter:  Joey Wilhelm |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Matthew Schinckel):

 Oh, it is worth pointing out that this is something that should be easy to
 package up in a reusable manner, since it (probably) won't require any
 changes, just the addition of a new class.

 That class could then be imported from anywhere.

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

Re: [Django] #28805: Provide a new database function for RegexpReplace

2017-11-16 Thread Django

#28805: Provide a new database function for RegexpReplace
-+-
 Reporter:  Joey Wilhelm |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Matthew Schinckel):

 Personally, I'd create it in the {{{django.contrib.postgres}}} section:
 there are already other functions in there that you should be able to look
 at how they are written.

 The other alternative is to put it in
 {{{django.db.models.functions.text}}}, but I'm not sure how to flag that
 it only works on specific backends there.

 You might want to bring this up on the django-developers list, as that
 sometimes gets a bit more notice.

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

Re: [Django] #28804: MariaDB compatibility broken: "Unknown system variable 'transaction_isolation'" (was: mysql backend error: 1193, "Unknown system variable 'transaction_isolation'")

2017-11-16 Thread Django

#28804: MariaDB compatibility broken: "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:  Accepted
  transaction_isolation, database,   |
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Adam (Chainz) Johnson (added)
 * stage:  Unreviewed => Accepted


Comment:

 The fix from #28794 fixes a deprecation warning in MySQL 5.7. It seems
 that MariaDB didn't make a similar change, or at least the version you're
 using didn't. Django doesn't officially support MariaDB but it likely
 practical to add a workaround here since it otherwise mostly works.

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Usually we've removed things in `django.utils` once Django no longer uses
 it. Offhand, I can't think of something in there that Django doesn't use.

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

[Django] #28806: Mechanism of fetching related objects violates READ COMMITTED assumption of Django ORM

2017-11-16 Thread Django

#28806: Mechanism of fetching related objects violates READ COMMITTED 
assumption of
Django ORM
-+-
   Reporter:  Aaron Tan  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:  database, read-
   Severity:  Normal |  committed, concurrency control
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Found here:
 
https://github.com/django/django/blob/master/django/db/models/fields/related_descriptors.py#L141.
 {{{
 def get_object(self, instance):
 qs = self.get_queryset(instance=instance)
 # Assuming the database enforces foreign keys, this won't fail.
 return qs.get(self.field.get_reverse_related_filter(instance))
 }}}


 The comment in that function states: `# Assuming the database enforces
 foreign keys, this won't fail.`, but it's not the case. I will illustrate
 with a use case we met:

 Suppose we have 2 concurrent transactions A and B talking to the same
 Postgresql backend, and we have two models:
 {{{
 class Foo:
 pass

 class Bar:
 fk = ForeignKey(Foo, on_delete=models.SET_NULL)
 }}}
 populated by objects
 {{{
 foo = Foo()
 foo.save()
 bar = Bar(fk=foo)
 bar.save()
 }}}
 Transaction A runs
 {{{
 bar = Bar.objects.get(pk=)
 }}}
 Then transaction B runs
 {{{
 Foo.objects.get(pk=).delete()
 }}}
 If READ COMMITTED is assumed by Django, transaction A will see the db
 snapshot with `foo` deleted. But if transaction A subsequently did
 {{{
 bar.fk #Access foreign key field `fk` for the first time
 }}}

 Because the `get_object` method linked does not catch `ObjectDoesNotExist`
 exception tossed by `get`, the last `bar.fk` will raise
 `ObjectDoesNotExist`, thus contradicts the assumption

 > the database enforces foreign keys, this won't fail.

 We currently manually catch `ObjectDoesNotExist` but that makes code ugly,
 I suggest instantiate the related field to `None` in that case, instead of
 raising exception.

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

Re: [Django] #28804: mysql backend error: 1193, "Unknown system variable 'transaction_isolation'"

2017-11-16 Thread Django

#28804: mysql backend error: 1193, "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:
  transaction_isolation, database,   |  Unreviewed
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gene Sem):

 This bug dont exist in Django 2.0b1.

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

[Django] #28805: Provide a new database function for RegexpReplace

2017-11-16 Thread Django

#28805: Provide a new database function for RegexpReplace
-+-
   Reporter:  Joey   |  Owner:  nobody
  Wilhelm|
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I've created a database function in my own project to utilize
 `REGEXP_REPLACE`, and wanted to contribute it upstream. At a quick glance,
 it appears that this is only available on PostgreSQL and Oracle. So my
 main question would be, which route would be preferable for inclusion?
 Should this be added to the PostgreSQL-specific code and let Oracle
 languish, or would this require the addition of a new feature flag on
 database backends?

 With the former implementation, I have code ready to go. The latter, I
 would definitely want some guidance.

 This is of course all assuming that this feature is desired.

 Here is an example usage:


 {{{#!python
 MyModel.objects.annotate(no_letters=RegexpReplace(F('name'), r'[A-Za-z]+',
 ''))
 }}}

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

Re: [Django] #28804: mysql backend error: 1193, "Unknown system variable 'transaction_isolation'"

2017-11-16 Thread Django

#28804: mysql backend error: 1193, "Unknown system variable
'transaction_isolation'"
-+-
 Reporter:  Gene Sem |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  mysqldb, error,  | Triage Stage:
  transaction_isolation, database,   |  Unreviewed
  backend|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Gene Sem):

 * type:  Uncategorized => Bug


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

[Django] #28804: mysql backend error: 1193, "Unknown system variable 'transaction_isolation'"

2017-11-16 Thread Django

#28804: mysql backend error: 1193, "Unknown system variable
'transaction_isolation'"
-+-
   Reporter:  Gene Sem   |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.0
  layer (models, ORM)|   Keywords:  mysqldb, error,
   Severity:  Release|  transaction_isolation, database,
  blocker|  backend
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 got this error: _mysql_exceptions.OperationalError
 (1193, "Unknown system variable 'transaction_isolation'")

 OS: Windows, mysql 10.1.28 MariaDB,
 The codebase is fully tested and working fine under django 1.11
 Python 3.6.3 installed in C:\Py3\

 Full listing of error:


 {{{
 Traceback (most recent call last):
   File "C:\Py3\lib\site-packages\django\db\backends\utils.py", line 83, in
 _execute
 return self.cursor.execute(sql)
   File "C:\Py3\lib\site-packages\django\db\backends\mysql\base.py", line
 71, in execute
 return self.cursor.execute(query, args)
   File "C:\Py3\lib\site-packages\MySQLdb\cursors.py", line 250, in execute
 self.errorhandler(self, exc, value)
   File "C:\Py3\lib\site-packages\MySQLdb\connections.py", line 50, in
 defaulterrorhandler
 raise errorvalue
   File "C:\Py3\lib\site-packages\MySQLdb\cursors.py", line 247, in execute
 res = self._query(query)
   File "C:\Py3\lib\site-packages\MySQLdb\cursors.py", line 411, in _query
 rowcount = self._do_query(q)
   File "C:\Py3\lib\site-packages\MySQLdb\cursors.py", line 374, in
 _do_query
 db.query(q)
   File "C:\Py3\lib\site-packages\MySQLdb\connections.py", line 277, in
 query
 _mysql.connection.query(self, query)
 _mysql_exceptions.OperationalError: (1193, "Unknown system variable
 'transaction_isolation'")

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "core.py", line 9, in 
 execute_from_command_line(sys.argv)
   File "C:\Py3\lib\site-packages\django\core\management\__init__.py", line
 371, in execute_from_command_line
 utility.execute()
   File "C:\Py3\lib\site-packages\django\core\management\__init__.py", line
 365, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\Py3\lib\site-packages\django\core\management\base.py", line
 288, in run_from_argv
 self.execute(*args, **cmd_options)
   File "C:\Py3\lib\site-packages\django\core\management\base.py", line
 332, in execute
 self.check()
   File "C:\Py3\lib\site-packages\django\core\management\base.py", line
 364, in check
 include_deployment_checks=include_deployment_checks,
   File "C:\Py3\lib\site-packages\django\core\management\base.py", line
 351, in _run_checks
 return checks.run_checks(**kwargs)
   File "C:\Py3\lib\site-packages\django\core\checks\registry.py", line 73,
 in run_checks
 new_errors = check(app_configs=app_configs)
   File "C:\Py3\lib\site-packages\django\core\checks\model_checks.py", line
 27, in check_all_models
 errors.extend(model.check(**kwargs))
   File "C:\Py3\lib\site-packages\django\db\models\base.py", line 1200, in
 check
 errors.extend(cls._check_fields(**kwargs))
   File "C:\Py3\lib\site-packages\django\db\models\base.py", line 1272, in
 _check_fields
 errors.extend(field.check(**kwargs))
   File "C:\Py3\lib\site-packages\django\db\models\fields\__init__.py",
 line 894, in check
 errors = super().check(**kwargs)
   File "C:\Py3\lib\site-packages\django\db\models\fields\__init__.py",
 line 206, in check
 errors.extend(self._check_backend_specific_checks(**kwargs))
   File "C:\Py3\lib\site-packages\django\db\models\fields\__init__.py",
 line 303, in _check_backend_specific_checks
 return connections[db].validation.check_field(self, **kwargs)
   File "C:\Py3\lib\site-packages\django\db\backends\base\validation.py",
 line 21, in check_field
 field_type = field.db_type(self.connection)
   File "C:\Py3\lib\site-packages\django\db\models\fields\__init__.py",
 line 648, in db_type
 return connection.data_types[self.get_internal_type()] % data
   File "C:\Py3\lib\site-packages\django\utils\functional.py", line 36, in
 __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "C:\Py3\lib\site-packages\django\db\backends\mysql\base.py", line
 133, in data_types
 if self.features.supports_microsecond_precision:
   File "C:\Py3\lib\site-packages\django\utils\functional.py", line 36, in
 __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Lamb):

 Replying to [comment:6 Tim Graham]:
 > Only the `_REV` suffixed dictionaries are unused. My thinking is to
 remove them. `django/utils/dateformat.py` uses the other variables.

 Ahhh, my bad. Well, in that case I'd err in terms of completing it (ie.
 applying this patch).

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Only the `_REV` suffixed dictionaries are unused. My thinking is to remove
 them. `django/utils/dateformat.py` uses the other variables.

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Lamb):

 Replying to [comment:4 Tim Graham]:
 > I also wonder if these dictionaries merit a continued presence because
 they are English-centric. I didn't find any usage of them in a GitHub code
 search.

 That's a fair comment. Shall we just remove the entire file? I'd prefer it
 "complete" or gone, really :)

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

Re: [Django] #28800: List routes in the console

2017-11-16 Thread Django

* cc: Keryn Knight (added)

Comment:

Can I suggest that its worth taking to the developers mailing list to
discuss this possibility? As an anecdotal datapoint, I know I semi-
frequently make use such a command when coming into a project which I've
not previously been heavily involved with. The flat output (vs traversing
a list of `include()` usages) gives a decent overview on what's what, and
the `contrib.admindocs` package already provides a similar overview if
installed into the admin.

It also isn't a **huge** amount of new work (in my mind, because
[https://github.com/kezabelle/django-unfurl I wrote a similar thing to the
django-extensions command]) precisely because it can depend on the same
functions admindocs does. So the maintenance burden is arguably ''mostly''
already in place.

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

Re: [Django] #23577: Rename operations should rename indexes, constraints, sequences and triggers named after their former value

2017-11-16 Thread Django

#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
-+
 Reporter:  Chris Woytowitz  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Migrations   |  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 Tim Graham):

 I closed #28803 as a duplicate.

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

Re: [Django] #28803: When renaming foreign key indexes don't get renamed which breaks next migrations

2017-11-16 Thread Django

#28803: When renaming foreign key indexes don't get renamed which breaks next
migrations
-+--
 Reporter:  Jacek Bzdak  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.11
 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 Tim Graham):

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


Comment:

 Looks like a duplicate of #23577.

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

Re: [Django] #28802: PasswordResetForm has method send_email in the documentation but send_mail is the correct method

2017-11-16 Thread Django

#28802: PasswordResetForm has method send_email in the documentation but 
send_mail
is the correct method
+--
 Reporter:  Daniel Clayton  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--

Comment (by Tim Graham ):

 In [changeset:"1738592bd05d2526724ded69346d8548197ae49d" 1738592]:
 {{{
 #!CommitTicketReference repository=""
 revision="1738592bd05d2526724ded69346d8548197ae49d"
 [1.10.x] Fixed #28802 -- Fixed typo in docs/topics/auth/default.txt.

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

Re: [Django] #28802: PasswordResetForm has method send_email in the documentation but send_mail is the correct method

2017-11-16 Thread Django

#28802: PasswordResetForm has method send_email in the documentation but 
send_mail
is the correct method
+--
 Reporter:  Daniel Clayton  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--

Comment (by Tim Graham ):

 In [changeset:"97dfc30f5b97536fff0bc3cb2c9e34d0edf26f19" 97dfc30f]:
 {{{
 #!CommitTicketReference repository=""
 revision="97dfc30f5b97536fff0bc3cb2c9e34d0edf26f19"
 [1.8.x] Fixed #28802 -- Fixed typo in docs/topics/auth/default.txt.

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

Re: [Django] #28803: When renaming foreign key indexes don't get renamed which breaks next migrations

2017-11-16 Thread Django

#28803: When renaming foreign key indexes don't get renamed which breaks next
migrations
-+--
 Reporter:  Jacek Bzdak  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 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 Jacek Bzdak):

 * type:  Uncategorized => Bug


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

Re: [Django] #28801: Outdated translatable text of a contrib.auth literal

2017-11-16 Thread Django

Comment (by Ramiro Morales):

Hello Claude,

I think maybe it´s me who doesn't understand things re: our translations
workflow.

I assumed just before 2.0 RC1 was tagged there was a

{{{
Python/JS source code -┬--> django{,js}.{po,mo}
└--> Transifex
}}}
resync of the translations. And maybe a fetch of translations from
Transifex.

So I downloaded RC1 expecting to see up to date translations .

Now I'm realizing things seem to be actually OK on the Transifex side:
* Literals were extracted from the Python/JS source code
* They were pushed to Transifex (maybe using the Transifex CLI tools?)
* We translators worked on them

But the .po/.mo files on the `stable-2.0.x` branch aren't supposed to be
up to date at this point, but rather just before 2.0 final gets released.
And this is why I see incomplete translations when test driving 2.0 rc1.

So, if this is the case. Please free to disregard this ticket. And sorry
for the noise.

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

Re: [Django] #28802: PasswordResetForm has method send_email in the documentation but send_mail is the correct method

2017-11-16 Thread Django

#28802: PasswordResetForm has method send_email in the documentation but 
send_mail
is the correct method
+--
 Reporter:  Daniel Clayton  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--

Comment (by Tim Graham ):

 In [changeset:"18324f2e657c68947e110f96a1a529e1e6c3f55e" 18324f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="18324f2e657c68947e110f96a1a529e1e6c3f55e"
 [1.11.x] Fixed #28802 -- Fixed typo in docs/topics/auth/default.txt.

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

Re: [Django] #28803: When renaming foreign key indexes don't get renamed which breaks next migrations

2017-11-16 Thread Django

#28803: When renaming foreign key indexes don't get renamed which breaks next
migrations
---+--
 Reporter:  Jacek Bzdak|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.11
 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
---+--

Comment (by Jacek Bzdak):

 Workaround for this issue is, to add two Alter field migratons (before and
 after rename), one takes down the index other recreates it --- if you have
 large dataset probably you should just rename the index manually.

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

Re: [Django] #28802: PasswordResetForm has method send_email in the documentation but send_mail is the correct method

2017-11-16 Thread Django

#28802: PasswordResetForm has method send_email in the documentation but 
send_mail
is the correct method
+--
 Reporter:  Daniel Clayton  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--

Comment (by Tim Graham ):

 In [changeset:"2b3907cf74b7d4c15e50661c659f6b5ec7cb2f8d" 2b3907cf]:
 {{{
 #!CommitTicketReference repository=""
 revision="2b3907cf74b7d4c15e50661c659f6b5ec7cb2f8d"
 [2.0.x] Fixed #28802 -- Fixed typo in docs/topics/auth/default.txt.

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

Re: [Django] #28802: PasswordResetForm has method send_email in the documentation but send_mail is the correct method

2017-11-16 Thread Django

#28802: PasswordResetForm has method send_email in the documentation but 
send_mail
is the correct method
+--
 Reporter:  Daniel Clayton  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.auth|  Version:  1.11
 Severity:  Normal  |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"d392fc293c9439c19451e152f9560f24d1659563" d392fc29]:
 {{{
 #!CommitTicketReference repository=""
 revision="d392fc293c9439c19451e152f9560f24d1659563"
 Fixed #28802 -- Fixed typo in docs/topics/auth/default.txt.
 }}}

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

Re: [Django] #28803: When renaming foreign key indexes don't get renamed which breaks next migrations

2017-11-16 Thread Django

#28803: When renaming foreign key indexes don't get renamed which breaks next
migrations
---+--
 Reporter:  Jacek Bzdak|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.11
 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 Jacek Bzdak):

 * Attachment "index_migration.zip" added.

 Project that reproduces the issue

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

Re: [Django] #28803: When renaming foreign key indexes don't get renamed which breaks next migrations

2017-11-16 Thread Django

#28803: When renaming foreign key indexes don't get renamed which breaks next
migrations
---+--
 Reporter:  Jacek Bzdak|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.11
 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 Jacek Bzdak):

 * Attachment "index_migration.zip" added.

 Project that reproduces my issue.

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

[Django] #28803: When renaming foreign key indexes don't get renamed which breaks next migrations

2017-11-16 Thread Django

#28803: When renaming foreign key indexes don't get renamed which breaks next
migrations
-+
   Reporter:  Jacek Bzdak|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Migrations |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Here is what I did. I have following models:

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


 class SecondReferencedModel(models.Model):
pass


 class ReferenceeModel(models.Model):
   child = models.ForeignKey(ReferencedModel, default=None,
 on_delete=models.CASCADE)
 }}}

 I want to swichch ``ReferenceeModel.child`` to ``SecondReferencedModel``.

 I want to do it by:

 1) Renaming ``ReferenceeModel.child_old``
 2) Adding ``ReferenceeModel.child`` that points to proper model
 3) Some RunPython magic
 4) Delete  ``ReferenceeModel.child_old``

 Actual bug:

 {{{

 class Migration(migrations.Migration):

 initial = True

 dependencies = [
 ]

 operations = [
 migrations.CreateModel(
 name='ReferencedModel',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ],
 ),
 migrations.CreateModel(
 name='SecondReferencedModel',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ],
 ),
 migrations.CreateModel(
 name='ReferenceeModel',
 fields=[
 ('id', models.AutoField(auto_created=True,
 primary_key=True, serialize=False, verbose_name='ID')),
 ('child',
 models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
 to='index_error.ReferencedModel')),
 ],
 ),
 ]

 class Migration(migrations.Migration):

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

 operations = [
 migrations.RenameField(
 model_name='referenceemodel',
 old_name='child',
 new_name='child_copy',
 ),
 ]


 class Migration(migrations.Migration):

 dependencies = [
 ('index_error', '0002_auto_20171116_1505'),
 ]

 operations = [
 migrations.AddField(
 model_name='referenceemodel',
 name='child',
 field=models.ForeignKey(default=None,
 on_delete=django.db.models.deletion.CASCADE,
 to='index_error.SecondReferencedModel'),
 ),
 ]

 }}}

 Third migration explodes with following error:

 {{{django.db.utils.ProgrammingError: relation
 "index_error_referenceemodel_child_id_59ba6fc6" already exist }}}

 Which is due to the

 1) Field `` child = models.ForeignKey(ReferencedModel, ...)`` generates
 postgresql index named ``index_error_referenceemodel_child_id_59ba6fc6``
 2) RenameField operation doesn't update index name (but changes field
 name)
 3) When I try to create new field index names clash.

 My setup:

 * Django 1.11 (also broken in 2.0)
 * postgresql database

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I also wonder if these dictionaries merit a continued presence because
 they are English-centric. I didn't find any usage of them in a GitHub code
 search.

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

[Django] #28802: PasswordResetForm has method send_email in the documentation but send_mail is the correct method

2017-11-16 Thread Django

#28802: PasswordResetForm has method send_email in the documentation but 
send_mail
is the correct method
--+
   Reporter:  daniel-clayton  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.auth|Version:  1.11
   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   |
--+
 The documentation for PasswordResetForm has a typo.
 
[https://docs.djangoproject.com/en/1.11/topics/auth/default/#django.contrib.auth.forms.PasswordResetForm]
 It lists
 {{{
 send_email(subject_template_name, email_template_name, context,
 from_email, to_email, html_email_template_name=None)
 }}}
 as a method, the correct method name is:
 {{{
 send_mail(subject_template_name, email_template_name, context, from_email,
 to_email, html_email_template_name=None)
 }}}
 as seen here
 
[https://github.com/django/django/blob/master/django/contrib/auth/forms.py#L246]

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

Re: [Django] #28796: reverse() coerces bytes in args/kwargs to str which adds "b" prefixes to the ouput

2017-11-16 Thread Django

#28796: reverse() coerces bytes in args/kwargs to str which adds "b" prefixes to
the ouput
--+
 Reporter:  Nick  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.0
 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 Tim Graham ):

 In [changeset:"0f7b5b38b603e06d6e3c8bdeecd096ad7f305af6" 0f7b5b38]:
 {{{
 #!CommitTicketReference repository=""
 revision="0f7b5b38b603e06d6e3c8bdeecd096ad7f305af6"
 [2.0.x] Fixed #28796 -- Doc'd backwards incompatibility when reverse()
 receives bytestring args/kwargs.

 Due to 301de774c21d055e9e5a7073e5bffdb52bc71079.

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

Re: [Django] #28796: reverse() coerces bytes in args/kwargs to str which adds "b" prefixes to the ouput

2017-11-16 Thread Django

#28796: reverse() coerces bytes in args/kwargs to str which adds "b" prefixes to
the ouput
--+
 Reporter:  Nick  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.0
 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
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"6bf85ff7e3b837378589e449ba27be8971d9b14c" 6bf85ff]:
 {{{
 #!CommitTicketReference repository=""
 revision="6bf85ff7e3b837378589e449ba27be8971d9b14c"
 Fixed #28796 -- Doc'd backwards incompatibility when reverse() receives
 bytestring args/kwargs.

 Due to 301de774c21d055e9e5a7073e5bffdb52bc71079.
 }}}

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

Re: [Django] #28755: django.utils.translation.check_for_language doesn't check in the app folders

2017-11-16 Thread Django

#28755: django.utils.translation.check_for_language doesn't check in the app
folders
-+-
 Reporter:  Dorian Amouroux  |Owner:
 |  ChillarAnand
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * needs_tests:  0 => 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/072.c073f76a9740e0a3d1410b9640c64586%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24607: Serialization (and deserialization) of MTI models doesn't work with natural keys

2017-11-16 Thread Django

#24607: Serialization (and deserialization) of MTI models doesn't work with 
natural
keys
-+-
 Reporter:  Denys Duchier|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  master
  (Serialization)|
 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 Wai Yi Anthony Leung):

 * status:  assigned => new
 * owner:  Wai Yi Anthony Leung => (none)
 * 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/071.a4fd42707fe75584a67967f678dc3475%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28755: django.utils.translation.check_for_language doesn't check in the app folders

2017-11-16 Thread Django

#28755: django.utils.translation.check_for_language doesn't check in the app
folders
-+-
 Reporter:  Dorian Amouroux  |Owner:
 |  ChillarAnand
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 ChillarAnand):

 * cc: ChillarAnand (added)
 * has_patch:  0 => 1


Comment:

 PR -> https://github.com/django/django/pull/9351

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

Re: [Django] #28799: ModelFormSet is incorrectly considered as not valid if initial form is not changed and validate_min=True

2017-11-16 Thread Django

#28799: ModelFormSet is incorrectly considered as not valid if initial form is 
not
changed and validate_min=True
-+--
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 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
-+--

Old description:

> I encountered this while trying to migrate from 1.10 to 1.11,
> ModelFormSet that was valid on 1.10 became invalid on 1.11.
> Here's test case:
> {{{
> from django.db import models
>
> from django.test import TestCase
> from django.forms.models import modelformset_factory
>
> class Price(models.Model):
> quantity = models.PositiveIntegerField()
>
> class ModelFormsetTest(TestCase):
> def test_modelformset_validate_min_and_initial(self):
> data = {
> 'form-TOTAL_FORMS': '2',
> 'form-INITIAL_FORMS': '0',
> 'form-0-quantity': '1',
> }
>
> FormSet = modelformset_factory(Price, fields=('quantity',),
> min_num=1, validate_min=True)
> formset = FormSet(data, initial=[{'quantity': 1}])
> self.assertTrue(formset.is_valid())
> }}}
>
> Bisected to f5c6295797b8332134fd89e0209a18a1d1d45e0c.

New description:

 I encountered this while trying to migrate from 1.10 to 1.11, ModelFormSet
 that was valid on 1.10 became invalid on 1.11.
 Here's test case:
 {{{
 from django.db import models
 from django.forms.models import modelformset_factory
 from django.test import TestCase

 class Author(models.Model):
 name = models.CharField(max_length=100)

 class ModelFormsetTest(TestCase):
 def test_modelformset_validate_min_and_initial(self):
 data = {
 'form-TOTAL_FORMS': '2',
 'form-INITIAL_FORMS': '0',
 'form-0-name': 'a',
 'form-1-name': 'b',
 }

 FormSet = modelformset_factory(Author, min_num=2, exclude=(),
 validate_min=True)
 formset = FormSet(data=data, queryset=Author.objects.none(),
 initial=[{'name': 'a'}])
 self.assertTrue(formset.is_valid())
 self.assertTrue(len(formset.save()), 2)
 }}}

 Bisected to f5c6295797b8332134fd89e0209a18a1d1d45e0c.

--

Comment (by Sergey Fedoseev):

 I updated test to make it closer to my situation: `min_num=2,
 validate_min=True`,  the first form is unchanged, the second one is
 filled. In this case objects are created.

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

Re: [Django] #28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV & MONTHS_3/MONTHS_3_REV

2017-11-16 Thread Django

#28798: Add a MONTHS_REV dict to match WEEKDAYS/WEEKDAYS_REV &
MONTHS_3/MONTHS_3_REV
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  dates| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Lamb):

 Replying to [comment:2 Tim Graham]:
 > Have you found many projects using these dicts?

 I find myself reaching for them fairly often, particulary when making a
 custom-ish date dropdown or some (admittedly trivial) parsing.

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

Re: [Django] #28801: Outdated translatable text of a contrib.auth literal

2017-11-16 Thread Django

#28801: Outdated translatable text of a contrib.auth literal
-+-
 Reporter:  Ramiro Morales   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.0
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  transifex| Triage Stage:
  makemessages po catalog|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Hey Ramiro, this string changed between 1.11 and 2.0
 [c52ae33a0c0c0bbaa460607a8787e95fe983a2b9].
 Once Transifex translations for 2.0 will be fetched, I suppose the issue
 will be resolved, or maybe I didn't understand 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/064.3f3b803c41bd009e1a62155adab42deb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

52 matches

Mail list logo