Re: [Django] #33829: BaseConstraint.deconstruct() and __eq__ operators don't take violation_error_message into account.

[Django]

#33829: BaseConstraint.deconstruct() and __eq__ operators don't take
violation_error_message into account.
-+-
 Reporter:  Mariusz Felisiak |Owner:  twidi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d6e619e7-b99e6fad-a772-43cb-8277-12e9c753b327-00%40eu-central-1.amazonses.com.

Re: [Django] #33829: BaseConstraint.deconstruct() and __eq__ operators don't take violation_error_message into account. (was: BaseConstraint.deconstruct() doesn't take violation_error_message into acc

[Django]

#33829: BaseConstraint.deconstruct() and __eq__ operators don't take
violation_error_message into account.
-+-
 Reporter:  Mariusz Felisiak |Owner:  twidi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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
-+-

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d6e3a0a0-b1facfec-7e29-4db6-b130-00547a71ed5a-00%40eu-central-1.amazonses.com.

Re: [Django] #33829: BaseConstraint.deconstruct() doesn't take violation_error_message into account.

[Django]

#33829: BaseConstraint.deconstruct() doesn't take violation_error_message into
account.
-+-
 Reporter:  Mariusz Felisiak |Owner:  twidi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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 Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d6e151d4-c4a8ade0-33f4-44c9-9a0d-d7534721065c-00%40eu-central-1.amazonses.com.

[Django] #33829: BaseConstraint.deconstruct() doesn't take violation_error_message into account.

[Django]

#33829: BaseConstraint.deconstruct() doesn't take violation_error_message into
account.
-+-
   Reporter:  Mariusz|  Owner:  twidi
  Felisiak   |
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Thanks  Stéphane "Twidi" Angel  for the report.

 Regression in 667105877e6723c6985399803a364848891513cc.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d6d99f93-bdf7d7f0-8dab-4a31-8858-87ac453ff1a2-00%40eu-central-1.amazonses.com.

Re: [Django] #33820: Querying "null" on key transforms for JSONField returns wrong results on SQLite.

[Django]

#33820: Querying "null" on key transforms for JSONField returns wrong results on
SQLite.
-+-
 Reporter:  Johnny Metz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GergelyKovach):

 Seems like a type-juggling routine introduced in 4.0.0
 I am totally into type-juggling but this case, and actually blocking issue
 is a great example of the general confusion that a seemingly
 *simplification* - may lead to hold back on tech dev.

 TL;DR:
 - consider removing type juggling
 - keep principles up, regarding data type comparison

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d5a3c024-91f19df6-b316-46af-9d8e-45321b91a13e-00%40eu-central-1.amazonses.com.

Re: [Django] #33827: Use of old MySQL version generate unknown default_storage_engine.

[Django]

#33827: Use of old MySQL version generate unknown default_storage_engine.
-+-
 Reporter:  rv2931   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Mysql, database, | Triage Stage:
  database.backends, storage_engine  |  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:   => invalid


Comment:

 Django 3.2.x also [https://docs.djangoproject.com/en/3.2/ref/databases
 /#version-support requires MySQL 5.7 or later].

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d42fcc99-c8f31703-f09c-4bbb-8ad8-594dddb314b5-00%40eu-central-1.amazonses.com.

Re: [Django] #33827: Use of old MySQL version generate unknown default_storage_engine.

[Django]

#33827: Use of old MySQL version generate unknown default_storage_engine.
-+-
 Reporter:  rv2931   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Mysql, database, | Triage Stage:
  database.backends, storage_engine  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rv2931):

 * status:  closed => new
 * version:  4.0 => 3.2
 * resolution:  invalid =>


Comment:

 I reopen the ticket because the behaviour is the same in Django 3.2.14

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d3b2c5b3-0aa9b099-e66d-4617-bbe3-0d0b69d521fc-00%40eu-central-1.amazonses.com.

Re: [Django] #33826: delete_many()/set_many() crashes with empty values on Redis client .

[Django]

#33826: delete_many()/set_many() crashes with empty values on Redis client .
-+-
 Reporter:  Christos Kopanos |Owner:  Christos
 Type:   |  Kopanos
  Cleanup/optimization   |   Status:  closed
Component:  Core (Cache system)  |  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  redis| 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"608ab043f75f1f9c094de57d2fd678f522bb8243" 608ab043]:
 {{{
 #!CommitTicketReference repository=""
 revision="608ab043f75f1f9c094de57d2fd678f522bb8243"
 Fixed #33826 -- Fixed RedisCache.set_many()/delete_many() crash with an
 empty list.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d30c8850-d39f14c4-b1b8-4451-ad0a-0719ca4b3c3b-00%40eu-central-1.amazonses.com.

Re: [Django] #33828: Admin's autocomplete_fields don't autofocus when opened

[Django]

#33828: Admin's autocomplete_fields don't autofocus when opened
---+--
 Reporter:  flbraun|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  4.0
 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 Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Uncategorized => contrib.admin


Comment:

 Duplicate of #33504.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d30aad6d-aea6008c-23e2-4bef-938f-88fceae49fa4-00%40eu-central-1.amazonses.com.

[Django] #33828: Admin's autocomplete_fields don't autofocus when opened

[Django]

#33828: Admin's autocomplete_fields don't autofocus when opened
-+
   Reporter:  flbraun|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  4.0
   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  |
-+
 After upgrading from Django 3.2 to 4.0, fields utilizing the Select2
 widget in the admin don't get autofocus on their search field when clicked
 on any more.

 There is an [https://github.com/select2/select2/issues/5993 open bug] with
 Select2 regarding autofocus issues with jQuery 3.6.0. Django 4.0 upgraded
 the vendored jQuery to that exact version, so I guess that's where the
 issue comes from.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d307a061-c988a34a-6944-40ff-a764-901bdedc12a5-00%40eu-central-1.amazonses.com.

Re: [Django] #33826: delete_many()/set_many() crashes with empty values on Redis client .

[Django]

#33826: delete_many()/set_many() crashes with empty values on Redis client .
-+-
 Reporter:  Christos Kopanos |Owner:  Christos
 Type:   |  Kopanos
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  redis| 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 Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d2f0f0ca-5f5d1095-bd43-4436-8210-dcc879483e97-00%40eu-central-1.amazonses.com.

Re: [Django] #33823: inspectdb should generate related_name on same relation links.

[Django]

#33823: inspectdb should generate related_name on same relation links.
-+-
 Reporter:  whysage  |Owner:  whysage
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"3926e35aa8c947b4c87aea33546b2e45347eaaa3" 3926e35a]:
 {{{
 #!CommitTicketReference repository=""
 revision="3926e35aa8c947b4c87aea33546b2e45347eaaa3"
 Fixed #33823 -- Made inspectdb generate unique related_name when reverse
 accessor clashes.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d29f4ab2-086c9d0c-d738-421d-9452-1d5c87dc9480-00%40eu-central-1.amazonses.com.

Re: [Django] #31536: Disabled clearable file field widget is not disabling the checkbox

[Django]

#31536: Disabled clearable file field widget is not disabling the checkbox
-+-
 Reporter:  Carles Pina Estany   |Owner:  Carles
 |  Pina Estany
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  form, filefield, | Triage Stage:  Ready for
  clearable_file_input   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by suspectpart):

 It seems like the fix to this issue raised a problem similar to Ticket
 #32681: Not checking whether the `disabled` attribute actually exists on
 the `attrs` of the 'clear' checkbox causes a `VariableDoesNotExist`
 exception to be logged every time the template is rendered with a checkbox
 that has no `disabled` atrribute:

 {{{
 [2022-07-06 10:06:03,452] DEBUG django.template base: Exception while
 resolving variable 'disabled' in template
 'admin/widgets/clearable_file_input.html'.
 Traceback (most recent call last):
   File "/home/horst/some_project/venv/lib/python3.10/site-
 packages/django/template/base.py", line 875, in _resolve_lookup
 current = current[bit]
 KeyError: 'disabled'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/horst/some_project/venv/lib/python3.10/site-
 packages/django/template/base.py", line 885, in _resolve_lookup
 current = getattr(current, bit)
 AttributeError: 'dict' object has no attribute 'disabled'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/horst/some_project/venv/lib/python3.10/site-
 packages/django/template/base.py", line 891, in _resolve_lookup
 current = current[int(bit)]
 ValueError: invalid literal for int() with base 10: 'disabled'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/horst/some_project/venv/lib/python3.10/site-
 packages/django/template/base.py", line 898, in _resolve_lookup
 raise VariableDoesNotExist(
 django.template.base.VariableDoesNotExist: Failed lookup for key
 [disabled] in {'id': 'id_document'}
 }}}

 Should this be a new 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d29c6803-8d6c61ee-2ce9-4cc6-8af4-13dfba2ccacf-00%40eu-central-1.amazonses.com.

Re: [Django] #33827: Use of old MySQL version generate unknown default_storage_engine. (was: Use of old MySQL version generate unknown default_storage_engine but no way to remove/replace parameter by

[Django]

#33827: Use of old MySQL version generate unknown default_storage_engine.
-+-
 Reporter:  rv2931   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Mysql, database, | Triage Stage:
  database.backends, storage_engine  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 `default_storage_engine` was introduced in MySQL 5.5.3 and Django 4.0+
 support MySQL 5.7 and higher.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d28e4841-dd5261a6-d1b5-40e9-a913-59c0e03abc02-00%40eu-central-1.amazonses.com.

Re: [Django] #33827: Use of old MySQL version generate unknown default_storage_engine but no way to remove/replace parameter by storage_engine

[Django]

#33827: Use of old MySQL version generate unknown default_storage_engine but no 
way
to remove/replace parameter by storage_engine
-+-
 Reporter:  rv2931   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Mysql, database, | Triage Stage:
  database.backends, storage_engine  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rv2931):

 * component:  Uncategorized => Database layer (models, ORM)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d2852c73-84043ae1-4af4-472d-9942-91ab90e46f12-00%40eu-central-1.amazonses.com.

[Django] #33827: Use of old MySQL version generate unknown default_storage_engine but no way to remove/replace parameter by storage_engine

[Django]

#33827: Use of old MySQL version generate unknown default_storage_engine but no 
way
to remove/replace parameter by storage_engine
-+-
   Reporter:  rv2931 |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  4.0
  Uncategorized  |   Keywords:  Mysql, database,
   Severity:  Normal |  database.backends, storage_engine
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi
 I meet the error
 {{{
 (1193, "Unknown system variable 'default_storage_engine'")
 }}}

 because I'm using an old MySQL version that is waiting for storage_engine
 and not default_storage_engine
 I've tried to add storage_engine in configuration but the
 default_storage_engin is still used, maybe in addition to storage_engine,
 and so still generate the error

 {{{
 DATABASES:{
 'default':{}
 'mysqldb': {
 'ENGINE': 'django.db.backends.mysql',
 'HOST': '',
 'PORT': '3306',
 'USER': '',
 'PASSWORD': '',
 'NAME': 'bi_entrepot',
 'STORAGE_ENGINE': 'MyISAM',
 'OPTIONS': {
  'init_command': 'SET storage_engine=MyISAM',
 }
 }
 }}}


 I looked for solution but didn't find any way to solve my situation
 because I have to use this old version of MySQL

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d284238c-5a4b8a08-abd3-4407-a545-168248be170d-00%40eu-central-1.amazonses.com.

Re: [Django] #33823: inspectdb should generate related_name on same relation links.

[Django]

#33823: inspectdb should generate related_name on same relation links.
-+-
 Reporter:  whysage  |Owner:  whysage
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  dev
  commands)  |
 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 Mariusz Felisiak):

 * needs_tests:  1 => 0
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070181d270bd0d-483816cb-5235-41bc-bd6a-b9b0f17ab69f-00%40eu-central-1.amazonses.com.