date:20160906

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gerricom):

 Replying to [comment:4 claudep]:
 > I'm wondering if we should continue this way with this special usage.
 Wouldn't the right solution to subclass the MySQL backend and adapt the
 checks?

 This is for sure no problem for us if we run into another problems in
 future. But in this specific case I believe there can be other cases where
 this error could occur. I've attached a little patch, that works for us.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gerricom):

 * Attachment "27180.diff" added.


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

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

Re: [Django] #4304: a second dev. web server does not report an err if bound to the same port

2016-09-06 Thread Django

#4304: a second dev. web server does not report an err if bound to the same port
-+-
 Reporter:  rogerpack2005@…  |Owner:  adrian
 Type:  Uncategorized|   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by hamidhaghshenas):

 * status:  closed => new
 * severity:   => Normal
 * resolution:  fixed =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 Replying to [ticket:4304 rogerpack2005@…]:
 > So...seems that on win32 (at least) if you start a server python
 manage.py runserver
 > then start another
 > python manage.py runserver
 > the first is really running, and the second doesn't an error but happily
 tells you it is running. This is a problem at times :)  Thanks!

 I have the same problem with Django 1.10.1 and Windows 7 64-bit.
 I was started a Django project on port 8000, then created a new Django
 project (with Django 1.10.1) and ran the server.
 It said that the server has been started successfully on port 8000, but
 browsing localhost:8000 showed the previous project's page.

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

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

2016-09-06 Thread Django

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by charettes):

 @jrhouston, the following should do:

 {{{#!python
 from django.contrib.postgres.fields.jsonb import KeyTransform
 from django.db.functions import Cast

 instance = JSONModel.objects.create(field={'foo': 123})
 foo = JSONModel.objects.annotate(
 foo=Cast(KeyTransform('foo', 'field'), models.IntegerField())
 ).values_list('foo', flat=True).get(pk=instance.pk)
 self.assertEqual(foo, 123)
 }}}

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

Re: [Django] #27172: Close cursor in custom SQL example

2016-09-06 Thread Django

#27172: Close cursor in custom SQL example
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by berkerpeksag):

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

Re: [Django] #27189: Allow namespaced management commands (was: Namespace management commands?)

2016-09-06 Thread Django

#27189: Allow namespaced management commands
-+-
 Reporter:  john-bonachon|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => needsinfo
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => New feature


Comment:

 I'm not aware of any recent discussion. I know of some third-party
 solutions such as [https://pypi.python.org/pypi/django-subcommand/ django-
 subcommand]. Anyway, it would be better to bring this up on the
 DevelopersMailingList. If there's consensus on a concrete proposal, we can
 reopen the ticket. Thanks.

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

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

Re: [Django] #27188: Allow using unique=True with FileField

2016-09-06 Thread Django

#27188: Allow using unique=True with FileField
--+
 Reporter:  jribbens  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by jribbens):

 That's great! If this works then presumably there's no reason the
 `primary_key` prevention check should be there either...

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

[Django] #27189: Namespace management commands?

2016-09-06 Thread Django

#27189: Namespace management commands?
+
 Reporter:  john-bonachon   |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Core (Management commands)  |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I always think management commands should be namespaced. ie.

 `python manage.py app:command`

 It's very normal to have the same command name for different apps.

 It isn't a problem really, but it would be more elegant.
 Is it already discussed? Is it too late? Why it could be a bad idea?

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

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

Re: [Django] #11385: DateTimeField doesn't accept ISO 8601 formatted date string

2016-09-06 Thread Django

#11385: DateTimeField doesn't accept ISO 8601 formatted date string
-+
 Reporter:  jtiai|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  datetime orm format  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by julen):

 As kmike mentioned above, customizing the form field with an
 `input_formats` containing the timezone marker `%z` doesn't help — at
 least on Python 2.7. For anyone hitting this, I worked around it by using
 a custom form field and overriding the `strptime` method:



 {{{
 from django.utils.dateparse import parse_datetime
 from django.utils.encoding import force_str


 class ISODateTimeField(forms.DateTimeField):

 def strptime(self, value, format):
 return parse_datetime(force_str(value))
 }}}

 I use Django's own `parse_datetime` utility. Note this is limited to ISO
 datetimes, and effectively any `input_formats` are omitted.

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

Re: [Django] #27178: ImageField when default provided in model, it's impossible to change the value.

2016-09-06 Thread Django

#27178: ImageField when default provided in model, it's impossible to change the
value.
-+-
 Reporter:  phonkee  |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * 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.bd3508b4c8316e220a7d64171a78eb24%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27186: Cannot change DateTimeField with default via Admin since Django 1.10.1

2016-09-06 Thread Django

#27186: Cannot change DateTimeField with default via Admin since Django 1.10.1
-+-
 Reporter:  michael-k|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * 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/067.16e9fb61837417a21d3a17cabf30813c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #4345: FileField cannot be used with unique=True

2016-09-06 Thread Django

#4345: FileField cannot be used with unique=True
-+-
 Reporter:  Fabian Fagerholm |Owner:  Gulopine
|
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  fs-rf-fixed  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * ui_ux:   => 0
 * type:   => Bug
 * severity:   => Normal
 * easy:   => 0


Comment:

 #27188 is a follow up ticket that argues to allow using `unique=True` with
 `FileField`.

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

Re: [Django] #27188: Allow using unique=True with FileField

2016-09-06 Thread Django

#27188: Allow using unique=True with FileField
--+
 Reporter:  jribbens  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * Attachment "27188.diff" added.


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

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

Re: [Django] #27188: Allow using unique=True with FileField (was: FileField cannot be used with unique=True)

2016-09-06 Thread Django

#27188: Allow using unique=True with FileField
--+
 Reporter:  jribbens  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 I did a quick check and didn't get the "can't adapt" error from #4345 when
 uploading to a unique `ImageField` in the admin. I'm attaching a partial
 patch, missing tests and release notes. Probably at least a test in
 `tests/model_fields/test_filefield.py` that verifies unique validation
 works correct is needed. It would be good to do some manual testing to try
 to identify anything that doesn't work.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I'm not sure how much ongoing work it would add to support this but if the
 backend has otherwise been usable since some old version of Django, then
 it seem reasonable to try to continue that as long as only minor changes
 are needed. We could also demote such issues from release blockers and
 require people using these special connections to submit patches
 themselves.

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

Re: [Django] #27187: Django 1.10 is unable to unpickle models pickled in Django pre-1.10

2016-09-06 Thread Django

#27187: Django 1.10 is unable to unpickle models pickled in Django pre-1.10
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (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 timgraham):

 The consensus from #21430 seemed to be that cross-version pickling support
 wasn't something we wanted to try to do. I guess you could ask on the
 mailing list whether we should revisit that.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 I'm wondering if we should continue this way with this special usage.
 Wouldn't the right solution to subclass the MySQL backend and adapt the
 checks?

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

[Django] #27188: FileField cannot be used with unique=True

2016-09-06 Thread Django

#27188: FileField cannot be used with unique=True
--+
 Reporter:  jribbens  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  File uploads/storage  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 In #4345 , code was added which explicitly prevents the use of
 `unique=True` on `FileField` fields. This seems bizarre and wrong, since
 making unique FileFields not only makes sense, it would be rare for
 ''not'' making them unique to make sense - after all, you can't have two
 different files with the same filename! Not allowing `unique=True` leads
 to impaired data integrity as the database can't therefore enforce the
 necessary uniqueness of filenames. (Looking at the previous ticket, it
 appears people were confused that it would be the file contents that was
 supposed to be unique, not the filenames.)

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

[Django] #27187: Django 1.10 is unable to unpickle models pickled in Django pre-1.10

2016-09-06 Thread Django

#27187: Django 1.10 is unable to unpickle models pickled in Django pre-1.10
-+-
   Reporter:  claudep|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  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  |
-+-
 Commit [7f51876f99851fdc3fef63aecdfbcffa199c26b9] changed the unpickle
 strategy for models. Now when I have old pickled models (for example in a
 queue) that I'm trying to unpickle with Django 1.10, I'm getting those
 errors:

 {{{
 UnpickleError at /django-rq/queues/1/
 (u'Could not unpickle', AttributeError("'module' object has no attribute
 'simple_class_factory'",))
 }}}
 And if I manually re-introduce `simple_class_factory`, I'm then getting:
 {{{
 UnpickleError at /django-rq/queues/1/
 (u'Could not unpickle', TypeError('model_unpickle() takes exactly 1
 argument (3 given)', ,
 (('accounts', 'BDNUser'), [], )))
 }}}

 Which could be solved by adding `*args` to `model_unpickle`.
 What about adding some compatibility shims during one or two releases?

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

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

Re: [Django] #27184: Test client crashes when uploading TemporaryFile on Unix

2016-09-06 Thread Django

#27184: Test client crashes when uploading TemporaryFile on Unix
-+-
 Reporter:  joonsikjang  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  test TemporaryFile   | Triage Stage:  Accepted
  django client file upload  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by claudep):

 * version:  1.9 => master
 * easy:  0 => 1


Comment:

 This should be relatively easy to fix by testing the type of file.name.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 From #26991, "I'm connecting via MySQL to an sphinxsearch database. It
 basically uses the MySQL query language but has some special features."

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Could we know a bit more about that `special database connection`, please?

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

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

Re: [Django] #27183: JSONField improperly escaped in admin interface during normal usage

2016-09-06 Thread Django

#27183: JSONField improperly escaped in admin interface during normal usage
---+--
 Reporter:  sjuxax |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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 timgraham):

 I still can't reproduce. What's your valid JSON input? It would be useful
 to know if you can reproduce without Mezzanine to rule out an issue there.

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

Re: [Django] #27184: Test client crashes when uploading TemporaryFile on Unix (was: django test client bug when use TemporaryFile in Mac)

2016-09-06 Thread Django

#27184: Test client crashes when uploading TemporaryFile on Unix
-+-
 Reporter:  joonsikjang  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  test TemporaryFile   | Triage Stage:  Accepted
  django client file upload  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure if this should/can work, but if not, it would be nice to have
 a friendlier message rather than a crash.

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

Re: [Django] #24865: Add a management command to remove stale content types

2016-09-06 Thread Django

#24865: Add a management command to remove stale content types
-+-
 Reporter:  Protosac |Owner:  Tim
 |  Graham 
 Type:  New feature  |   Status:  closed
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  stale contenttypes   | 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 Tim Graham ):

 * status:  new => closed
 * owner:   => Tim Graham 
 * resolution:   => fixed


Comment:

 In [changeset:"6a2af01452966d10155b720f4f5e7b09c7e3e419" 6a2af014]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a2af01452966d10155b720f4f5e7b09c7e3e419"
 Fixed #24865 -- Added remove_stale_contenttypes management command.

 Thanks Simon Charette for the review.
 }}}

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

Re: [Django] #27181: Sites framework does not normalize domains with trailing "."

2016-09-06 Thread Django

#27181: Sites framework does not normalize domains with trailing "."
---+
 Reporter:  bluetech   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.sites  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Perhaps `http.request.split_domain_port()` should remove the trailing dot
 rather than `validate_host()` looking for the trailing dot.

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

Re: [Django] #27183: JSONField improperly escaped in admin interface during normal usage

2016-09-06 Thread Django

Comment (by sjuxax):

It should be noted that I am also using Mezzanine and seeing this issue
through Mezzanine's admin interface, though I haven't found this issue to
exist in Mezzanine's code -- as I said, the fix that's working for me is
in contrib/postgres/forms/jsonb.py. I haven't tested non-Mezzanine. I'm
using PgSQL 9.5.4, Django 1.10.1, Mezzanine git head (06b3df5380a5a),
Python 3.5.2.

Steps to reproduce: create a django.contrib.postgres.fields.JSONField in a
model. Migrate. Make sure the model is registered for admin. Load up the
admin. Input valid JSON into the JSONField and save. Open the newly-added
record in the admin. Observe that the JSONField is improperly escaped.

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

Re: [Django] #27185: Can not change value in DateTimeField in Admin when default is set

2016-09-06 Thread Django

#27185: Can not change value in DateTimeField in Admin when default is set
---+--
 Reporter:  nvlbud |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Duplicate of #27186

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

Re: [Django] #27183: JSONField improperly escaped in admin interface during normal usage

2016-09-06 Thread Django

#27183: JSONField improperly escaped in admin interface during normal usage
---+--
 Reporter:  sjuxax |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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 timgraham):

 Are you using Django 1.10? What are the steps to reproduce?

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

Re: [Django] #27178: ImageField when default provided in model, it's impossible to change the value.

2016-09-06 Thread Django

#27178: ImageField when default provided in model, it's impossible to change the
value.
-+
 Reporter:  phonkee  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => Forms
 * severity:  Normal => Release blocker


Old description:

> When I set model with ImageField that has default value set, it's
> impossible to change this value.
>
> class TestModel(models.Model)
> image = ImageField(default="default.jpg")
>
> Now it's impossible to change the value from ModelForm's and/or admin.

New description:

 When I set model with ImageField that has default value set, it's
 impossible to change this value.
 {{{
 class TestModel(models.Model):
 image = models.ImageField(default="default.jpg")
 }}}
 Now it's impossible to change the value from ModelForm's and/or admin.

--

Comment:

 Regression in 1.10.1 caused by 4bc6b939944183533ae74791d21282e613f63a96.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-06 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * component:  Migrations => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * 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.80f797fddce2efe2ee2b0752c83f8ef9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27184: django test client bug when use TemporaryFile in Mac

2016-09-06 Thread Django

#27184: django test client bug when use TemporaryFile  in Mac
-+-
 Reporter:  joonsikjang  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  test TemporaryFile   | Triage Stage:
  django client file upload  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Old description:

> below code is file upload test method
> This code was generated error message when I test only in Mac.
> This code was ok when I test in Windows 10.
> if I change TemporaryFile to NamedTemporaryFile, then It work correctly.
>

> {{{
> def test_ChunkedSampleFile(self):
> """
> ChunkedSampleFileList, ChunkedSampleFileDetail View Test
> """
> with TemporaryFile() as test_file:
> for count in range(10):
> test_file.write(('test_data %s' % count).encode())
> test_file.seek(0)
> hash_md5 = hashlib.md5()
> for chunk in iter(lambda: test_file.read(4096), b""):
> hash_md5.update(chunk)
> etag = hash_md5.hexdigest()
> test_file.seek(0)
>
> #post
> response = self.client.post('%s/chunked_sample_files' %
> URL_PREFIX,
> data={'file': test_file, 'name': 'test.vcf',
>   'sample_file_meta':
> self.sample_file_meta_id,
>   'file_seq': 1, 'etag': etag},
> **{AUTH_TOKEN_HEADER_NAME: 'Token %s' %
> self.testuserfastqc1_token} )
> self.assertEqual(response.status_code,
> status.HTTP_201_CREATED, response.content)
> file_id = response.json()['id']
> }}}
>
> Error Message
>
> ERROR: test_ChunkedSampleFile
> (analysis_files.tests.AnalysisFilesTestCase)
> --
> Traceback (most recent call last):
>   File
> "/Users/joonsik/git/ngenebio_webapi/ngenebio_webapi/analysis_files/tests.py",
> line 174, in test_ChunkedSampleFile
> **{AUTH_TOKEN_HEADER_NAME: 'Token %s' % self.testuserfastqc1_token} )
>   File "/Users/joonsik/venv_ngenebio_webapi/lib/python3.4/site-
> packages/django/test/client.py", line 515, in post
> secure=secure, **extra)
>   File "/Users/joonsik/venv_ngenebio_webapi/lib/python3.4/site-
> packages/django/test/client.py", line 311, in post
> post_data = self._encode_data(data, content_type)
>   File "/Users/joonsik/venv_ngenebio_webapi/lib/python3.4/site-
> packages/django/test/client.py", line 275, in _encode_data
> return encode_multipart(BOUNDARY, data)
>   File "/Users/joonsik/venv_ngenebio_webapi/lib/python3.4/site-
> packages/django/test/client.py", line 171, in encode_multipart
> lines.extend(encode_file(boundary, key, value))
>   File "/Users/joonsik/venv_ngenebio_webapi/lib/python3.4/site-
> packages/django/test/client.py", line 200, in encode_file
> filename = os.path.basename(file.name) if hasattr(file, 'name') else
> ''
>   File "/Users/joonsik/venv_ngenebio_webapi/lib/python3.4/posixpath.py",
> line 139, in basename
> i = p.rfind(sep) + 1
> AttributeError: 'int' object has no attribute 'rfind'

New description:

 below code is file upload test method
 This code was generated error message when I test only in Mac.
 This code was ok when I test in Windows 10.
 if I change TemporaryFile to NamedTemporaryFile, then It work correctly.


 {{{
 def test_ChunkedSampleFile(self):
 """
 ChunkedSampleFileList, ChunkedSampleFileDetail View Test
 """
 with TemporaryFile() as test_file:
 for count in range(10):
 test_file.write(('test_data %s' % count).encode())
 test_file.seek(0)
 hash_md5 = hashlib.md5()
 for chunk in iter(lambda: test_file.read(4096), b""):
 hash_md5.update(chunk)
 etag = hash_md5.hexdigest()
 test_file.seek(0)

 #post
 response = self.client.post('%s/chunked_sample_files' %
 URL_PREFIX,
 data={'file': test_file, 'name': 'test.vcf',
   'sample_file_meta':
 self.sample_file_meta_id,
   'file_seq': 1, 'etag': etag},
 **{AUTH_TOKEN_HEADER_NAME: 'Token %s' %
 self.testuserfastqc1_token} )
 self.assertEqual(response.status_code,
 status

Re: [Django] #27186: Cannot change DateTimeField with default via Admin since Django 1.10.1

2016-09-06 Thread Django

#27186: Cannot change DateTimeField with default via Admin since Django 1.10.1
-+
 Reporter:  michael-k|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * 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/067.e49bc6e5a5efa77c47c408f4096903f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27159: Pickling query from queryset causes unintended queryset evaluation

2016-09-06 Thread Django

#27159: Pickling query from queryset causes unintended queryset evaluation
-+-
 Reporter:  jtiai|Owner:  DavidFozo
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by DavidFozo):

 * Attachment "ticket_27159.diff" added.


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

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

Re: [Django] #27159: Pickling query from queryset causes unintended queryset evaluation

2016-09-06 Thread Django

#27159: Pickling query from queryset causes unintended queryset evaluation
-+-
 Reporter:  jtiai|Owner:  DavidFozo
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 DavidFozo):

 I deleted `self._fetch_all()` from `django/db/models/query.py
 QuerySet.__getstate__ `, so now it doesn't populate the cache before
 pickling. Is it a valid solution? All tests are passing.

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

Re: [Django] #27186: Cannot change DateTimeField with default via Admin since Django 1.10.1

2016-09-06 Thread Django

#27186: Cannot change DateTimeField with default via Admin since Django 1.10.1
---+--
 Reporter:  michael-k  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.10
 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
---+--
Description changed by michael-k:

Old description:

> Since Django 1.10.1 (it worked in 1.10.0), it is not possible to change
> the value of a DateTimeField in the admin if the field has a default.
>
> Changing the value and saving the object results in the old value still
> being in the database.
>

> == How to reproduce ==
>
> I created a small [https://github.com/michael-k/datetimefieldbroken
> example project] to easily reproduce the problem.
>
> It has a
> [https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/models.py#L5-L7
> model ''Dummy''] with two DateTimeFields.  One ''with'' and one
> ''without'' a default (''django.utils.timezone.now'').  The
> [https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/admin.py#L6-L8
> admin] is the default ''django.contrib.admin.ModelAdmin''.
>

> {{{
> git clone https://github.com/michael-k/datetimefieldbroken.git && cd
> datetimefieldbroken
> docker-compose build --pull
> docker-compose run web migrate
> docker-compose run web createsuperuser
> docker-compose up -d
> }}}
>
> Head your browser to [http://localhost:8023/admin/main/dummy/add/], login
> and create a new ''Dummy'' using ''Save and continue editing''.  Change
> the values all for input fields and press ''Save and continue editing''
> again.  The values of ''Dt with default'' are unchanged.
>

>
> == Patch that introduced the issue ==
>
> We belive that [https://github.com/django/django/pull/7068 PR 7068]
> (regarding [https://code.djangoproject.com/ticket/27039 issue 27039])
> introduced the problem, but did not validate this.  Supposedly this
> happens because DateTimeField is split into two fields (date + time) in
> the admin.
>
> We tried it however with Django 1.10.0 and it works just fine.

New description:

 Since Django 1.10.1 (it worked in 1.10.0), it is not possible to change
 the value of a DateTimeField in the admin if the field has a default.

 Changing the value and saving the object results in the old value still
 being in the database.


 == How to reproduce ==

 I created a small [https://github.com/michael-k/datetimefieldbroken
 example project] to easily reproduce the problem.

 It has a
 
[https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/models.py#L5-L7
 model ''Dummy''] with two DateTimeFields.  One ''with'' and one
 ''without'' a default (''django.utils.timezone.now'').  The
 
[https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/admin.py#L6-L8
 admin] is the default ''django.contrib.admin.ModelAdmin''.


 {{{
 git clone https://github.com/michael-k/datetimefieldbroken.git && cd
 datetimefieldbroken
 docker-compose build --pull
 docker-compose run web migrate
 docker-compose run web createsuperuser
 docker-compose up -d
 }}}

 Head your browser to [http://localhost:8023/admin/main/dummy/add/], login
 and create a new ''Dummy'' using ''Save and continue editing''.  Change
 the values all for input fields and press ''Save and continue editing''
 again.  The values of ''Dt with default'' are unchanged.



 == Patch that introduced the issue ==

 We believe that [https://github.com/django/django/pull/7068 PR 7068]
 (regarding [https://code.djangoproject.com/ticket/27039 issue 27039])
 introduced the problem, but did not validate this.  Supposedly this
 happens because DateTimeField is split into two fields (date + time) in
 the admin.

 We tried it however with Django 1.10.0 and it works just fine.

--

--
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.cb9384b51fef22b8fbba61caf3c7b8dd%40djangopr

Re: [Django] #27186: Cannot change DateTimeField with default via Admin since Django 1.10.1

2016-09-06 Thread Django

#27186: Cannot change DateTimeField with default via Admin since Django 1.10.1
---+--
 Reporter:  michael-k  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  1.10
 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 michael-k):

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


Old description:

> Since Django 1.10.1 (it worked in 1.10.0), it is not possible to change
> the value of a DateTimeField in the admin if the field has a default.
>
> Changing the value and saving the object results in the old value still
> being in the database.
>

> == How to reproduce ==
>
> I created a small [https://github.com/michael-k/datetimefieldbroken
> example project] to easily reproduce the problem.
>
> It has a
> [https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/models.py#L5-L7
> model ''Dummy''] with two DateTimeFields.  One ''with'' and one
> ''without'' a default (''django.utils.timezone.now'').  The
> [https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/admin.py#L6-L8
> admin] is the default ''django.contrib.admin.ModelAdmin''.
>

> {{{
> git clone https://github.com/michael-k/datetimefieldbroken.git && cd
> datetimefieldbroken
> docker-compose build --pull
> docker-compose run web migrate
> docker-compose run web createsuperuser
> docker-compose up -d
> }}}
>
> Head your browser to [http://localhost:8023/admin/main/dummy/add/], login
> and create a new ''Dummy'' using ''Save and continue editing''.  Change
> the values all for input fields and press ''Save and continue editing''
> again.  The values of ''Dt with default'' are unchanged.
>

>
> == Patch that introduced the issue ==
>
> We belive that [https://github.com/django/django/pull/7195/files PR 7195]
> (redaring [https://code.djangoproject.com/ticket/27039 issue 27039])
> introduced the problem, but did not validate this.  Supposedly this
> happens because DateTimeField is split into two fields (date + time) in
> the admin.
>
> We tried it however with Django 1.10.0 and it works just fine.

New description:

 Since Django 1.10.1 (it worked in 1.10.0), it is not possible to change
 the value of a DateTimeField in the admin if the field has a default.

 Changing the value and saving the object results in the old value still
 being in the database.


 == How to reproduce ==

 I created a small [https://github.com/michael-k/datetimefieldbroken
 example project] to easily reproduce the problem.

 It has a
 
[https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/models.py#L5-L7
 model ''Dummy''] with two DateTimeFields.  One ''with'' and one
 ''without'' a default (''django.utils.timezone.now'').  The
 
[https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/admin.py#L6-L8
 admin] is the default ''django.contrib.admin.ModelAdmin''.


 {{{
 git clone https://github.com/michael-k/datetimefieldbroken.git && cd
 datetimefieldbroken
 docker-compose build --pull
 docker-compose run web migrate
 docker-compose run web createsuperuser
 docker-compose up -d
 }}}

 Head your browser to [http://localhost:8023/admin/main/dummy/add/], login
 and create a new ''Dummy'' using ''Save and continue editing''.  Change
 the values all for input fields and press ''Save and continue editing''
 again.  The values of ''Dt with default'' are unchanged.



 == Patch that introduced the issue ==

 We belive that [https://github.com/django/django/pull/7068 PR 7068]
 (regarding [https://code.djangoproject.com/ticket/27039 issue 27039])
 introduced the problem, but did not validate this.  Supposedly this
 happens because DateTimeField is split into two fields (date + time) in
 the admin.

 We tried it however with Django 1.10.0 and it works just fine.

--

--
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

[Django] #27186: Cannot change DateTimeField with default via Admin since Django 1.10.1

2016-09-06 Thread Django

#27186: Cannot change DateTimeField with default via Admin since Django 1.10.1
---+
 Reporter:  michael-k  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Since Django 1.10.1 (it worked in 1.10.0), it is not possible to change
 the value of a DateTimeField in the admin if the field has a default.

 Changing the value and saving the object results in the old value still
 being in the database.


 == How to reproduce ==

 I created a small [https://github.com/michael-k/datetimefieldbroken
 example project] to easily reproduce the problem.

 It has a
 
[https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/models.py#L5-L7
 model ''Dummy''] with two DateTimeFields.  One ''with'' and one
 ''without'' a default (''django.utils.timezone.now'').  The
 
[https://github.com/michael-k/datetimefieldbroken/blob/b6ff942dd328007bf4af199b91d20d6cbfbb09d5/datetimefieldbroken/main/admin.py#L6-L8
 admin] is the default ''django.contrib.admin.ModelAdmin''.


 {{{
 git clone https://github.com/michael-k/datetimefieldbroken.git && cd
 datetimefieldbroken
 docker-compose build --pull
 docker-compose run web migrate
 docker-compose run web createsuperuser
 docker-compose up -d
 }}}

 Head your browser to [http://localhost:8023/admin/main/dummy/add/], login
 and create a new ''Dummy'' using ''Save and continue editing''.  Change
 the values all for input fields and press ''Save and continue editing''
 again.  The values of ''Dt with default'' are unchanged.



 == Patch that introduced the issue ==

 We belive that [https://github.com/django/django/pull/7195/files PR 7195]
 (redaring [https://code.djangoproject.com/ticket/27039 issue 27039])
 introduced the problem, but did not validate this.  Supposedly this
 happens because DateTimeField is split into two fields (date + time) in
 the admin.

 We tried it however with Django 1.10.0 and it works just fine.

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

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

2016-09-06 Thread Django

#23919: Cleanups for when we drop Python 2 compatibility
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by funkybob:

Old description:

> This is a tracking ticket of things that we can remove when we drop
> Python 2 compatibility in Django 2.0. Please edit the description of the
> ticket as you come across new items.
>
> * `django.core.mail.message.make_msgid()` #23905
> * `django.dispatch.weakref_backports`
> * `django.http.cookie` workarounds
> * `django.utils.2to3_fixes`
> * `django.utils.decorators.ContextDecorator`
> * `django.utils.encoding`
>  * `@python_2_unicode_compatible`
>  * force/smart _unicode
>  * either force/smart _text or force/smart _str
> * `django.utils.html_parser.use_workaround`
> * `django.utils.http` functions like `urlquote_plus` -- I think the
> versions of these functions on Python 3 don't have the unicode characters
> bug we are working around.
> * `django.utils.lru_cache`
> * `django.utils.six`
> * `from __future__ import unicode_literals`
> * `str()` stuff for environment variables, e.g.
> 0bfb53866199f366ed140d49938fd185e5898156
> * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
> other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
> * `git grep 'long int'` (mostly docs)
> * `django.utils._os [npath,upath]`
> * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
> longer needed)
> * Support for pysqlite (doesn't support Python 3)
> * Replace `super(ClassName, self)` with `super()`
> * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
> default on Python 3)
> * Evaluate replacement of custom `__del__` methods by
> [https://docs.python.org/3/library/weakref.html#weakref.finalize
> weakref.finalize]
> * Remove `__ne__` from objects already defining a `__eq__`
> * Remove note about PYTHONHASHSEED (see #26243)
> * Remove Field.creation_counter (replace by metaclass `__prepare__`
> returning `OrderedDict()`,
> https://docs.python.org/3/reference/datamodel.html#preparing-the-class-
> namespace)
> * `django.test.utils.reset_warning_registry()`
> * Replace `errno` checks by `IOError` subclasses defined by
> [https://www.python.org/dev/peps/pep-3151/ PEP 3151]

New description:

 This is a tracking ticket of things that we can remove when we drop Python
 2 compatibility in Django 2.0. Please edit the description of the ticket
 as you come across new items.

 * `django.core.mail.message.make_msgid()` #23905
 * `django.dispatch.weakref_backports`
 * `django.http.cookie` workarounds
 * `django.utils.2to3_fixes`
 * `django.utils.decorators.ContextDecorator`
 * `django.utils.encoding`
  * `@python_2_unicode_compatible`
  * force/smart _unicode
  * either force/smart _text or force/smart _str
 * `django.utils.html_parser.use_workaround`
 * `django.utils.http` functions like `urlquote_plus` -- I think the
 versions of these functions on Python 3 don't have the unicode characters
 bug we are working around.
 * `django.utils.lru_cache`
 * `django.utils.six`
 * `from __future__ import unicode_literals`
 * `str()` stuff for environment variables, e.g.
 0bfb53866199f366ed140d49938fd185e5898156
 * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
 other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
 * `git grep 'long int'` (mostly docs)
 * `django.utils._os [npath,upath]`
 * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
 longer needed)
 * Support for pysqlite (doesn't support Python 3)
 * Replace `super(ClassName, self)` with `super()`
 * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
 default on Python 3)
 * Evaluate replacement of custom `__del__` methods by
 [https://docs.python.org/3/library/weakref.html#weakref.finalize
 weakref.finalize]
 * Remove `__ne__` from objects already defining a `__eq__`
 * Remove note about PYTHONHASHSEED (see #26243)
 * Remove Field.creation_counter (replace by metaclass `__prepare__`
 returning `OrderedDict()`,
 https://docs.python.org/3/reference/datamodel.html#preparing-the-class-
 namespace)
 * `django.test.utils.reset_warning_registry()`
 * Replace `errno` checks by `IOError` subclasses defined by
 [https://www.python.org/dev/peps/pep-3151/ PEP 3151]
 * `django.utils.glob`
 * `d

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

2016-09-06 Thread Django

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by jrhouston):

 @charettes in your last comment are you referring to the use of the
 regex/iregex lookup used in the pull request, and if so could you suggest
 an alternative lookup that I could use to test this?

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

Re: [Django] #27185: Can not change value in DateTimeField in Admin when default is set

2016-09-06 Thread Django

#27185: Can not change value in DateTimeField in Admin when default is set
---+
 Reporter:  nvlbud |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.10
 Severity:  Normal | Resolution:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by nvlbud):

 * Attachment "dateprj.zip" added.


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

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

[Django] #27185: Can not change value in DateTimeField in Admin when default is set

2016-09-06 Thread Django

#27185: Can not change value in DateTimeField in Admin when default is set
---+
 Reporter:  nvlbud |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In our project I have model like with set "default":

 {{{#!python
 from django.db import models
 from django.utils import timezone


 class DateModel(models.Model):
 dt = models.DateTimeField(default=timezone.now)
 date = models.DateField(default=timezone.now)
 tm = models.TimeField(default=timezone.now)

 }}}

 In admin interface on model page I edit values in all fields and then
 press "Save" or "Save or continue editing". Changes to DateTime field are
 not saved to database. Values in DateField and TimeField are saved.

 This bug appeared in Django 1.10.1. In Django 1.10 all values were saved.

 There is demo project demonstrating this behaviour in attachment (requires
 "Django==1.10.1" only).

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

Re: [Django] #27172: Close cursor in custom SQL example

2016-09-06 Thread Django

#27172: Close cursor in custom SQL example
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cjerdonek):

 * owner:  nobody => cjerdonek
 * 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/067.d1d337d7ca8d10227114eca13a4ff50d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27173: Permit import statements to be longer than 80 characters

2016-09-06 Thread Django

#27173: Permit import statements to be longer than 80 characters
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cjerdonek):

 Good point re: the 6K patch (which didn't occur to me).

 It's a shame that isort forces the code to be exactly "one way" as opposed
 to acting more as a linter and complaining only when there is
 nonconformance. That would permit incremental change (e.g. permitting the
 setting to change without having to make massive code changes) as well as
 not forcing Django to conform to buggy isort output.

 Regarding readability, I agree except in those cases where a longer line
 would permit the import to fit on one line. If it's more than one line
 either way, then I agree there's little or no benefit.

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

Re: [Django] #27173: Permit import statements to be longer than 80 characters

2016-09-06 Thread Django

#27173: Permit import statements to be longer than 80 characters
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I agree with Tim, perhaps this would work around the backslash issue for
 23 imports but it would also reduce readability for thousands of other
 imports.

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

Re: [Django] #27170: Make database backend init() methods friendlier to subclassing

2016-09-06 Thread Django

#27170: Make database backend __init__() methods friendlier to subclassing
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 cjerdonek):

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

46 matches

Mail list logo