[django/django] a36901: Fixed an I18N test class tearDown method.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a3690168cbde5e7bee16443569ad3dedd2466af7
  
https://github.com/django/django/commit/a3690168cbde5e7bee16443569ad3dedd2466af7
  Author: Ramiro Morales 
  Date:   2013-10-20 (Sun, 20 Oct 2013)

  Changed paths:
M tests/i18n/commands/extraction.py

  Log Message:
  ---
  Fixed an I18N test class tearDown method.



-- 
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/5264ab627bd9c_76fab6bd54102284%40hookshot-fe5-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20752: Error signals are not reliable, especially when dealing with database errors

[Django]

#20752: Error signals are not reliable, especially when dealing with database
errors
-+-
 Reporter:  tal@…|Owner:  schacki
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  signals errors   | Triage Stage:  Accepted
  databaseError  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ptone):

 * cc: preston@… (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/073.01090a7c8bc326ba785c304fe3134cd0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20382: random TransactionManagementError during tests in _fixture_setup

[Django]

#20382: random TransactionManagementError during tests in _fixture_setup
-+-
 Reporter:  joao@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
  TransactionManagementError |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by xme):

 I can confirm problem with tests (the same error message) and running in
 background server. Such a situation happens even if there is another port
 for dev and tests. Stopping dev server makes that tests pass.

-- 
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/077.ff40983ff413a2c2a06653ba30fc3ff0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21290: Add migration docs for (or avoid) "Cannot serialize" errors

[Django]

#21290: Add migration docs for (or avoid) "Cannot serialize" errors
--+
 Reporter:  timo  |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by loic84):

 I'd personally like to delay as much as possible the writing of the docs
 while things are still in motion, so we remain flexible with regards to
 the API. That said this is definitely a 1.7 release blocker.

 The general concept is that things need to be either of basic types
 (`str`, `int`, etc.) or be "importable", with their `__name__` attribute
 telling us how.

 This means that functions, and classes (actual `type`, not instances),
 work out of the box (as long as they are not trapped in a closure).

 Anything else can't be "guessed" and need to supply enough information so
 they can be reconstructed, to do so, they can expose a `deconstruct`
 attribute, which is a function that returns a triple (import_path
 , args , kwargs ).


 A few remarks:

 - One of the most common troublemakers is `lamba`, luckily it's easy to
 fix, just use a normal function instead.
 - My patch for #21275 provides a simple class decorator
 `@deconstructible`, which should work to reconstruct most class instances.
 - For advance usage, it's possible for an object's `deconstruct` method to
 point to an unrelated object, `models.SET` in
 d59f1993f150f83524051d96b52df08da4dcf011 takes advantage of that.
 - Right now, if the serializer encounters something it can't serialize, it
 just gives up. Ideally the interactive prompt would give a few options to
 choose from. For instance: 1. Cancel, 2. Set to NULL, 3. Continue with a
 marked error that needs to be hand edited (like for a merge conflict).

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

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

Re: [Django] #9722: Use pyinotify (where available) instead of polling filesystem every second to detect changes

[Django]

#9722: Use pyinotify (where available) instead of polling filesystem every 
second
to detect changes
-+-
 Reporter:  lamby|Owner:
 Type:  New feature  |  unaizalakain
Component:  Core (Management |   Status:  assigned
  commands)  |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 Apart from minor cleanup with trailing spaces, I can confirm the patch is
 working well on my Linux machine.

-- 
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.269322ec1a82457131b64875004aa3e3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21275: Cannot use migrations if model field specifies validators

[Django]

#21275: Cannot use migrations if model field specifies validators
+--
 Reporter:  timo|Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by loic84):

 * needs_tests:  1 => 0


Comment:

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

 Note that this will be needed if/when #21295 is merged.

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

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

Re: [Django] #21295: Add on_update support

[Django]

#21295: Add on_update support
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by loic84):

 * cc: loic@… (added)


Comment:

 Awesome work.

 I just had a brief look at the diff, it will need special handling to be
 compatible with migrations, my patch for #21275 addresses this issue.

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

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

Re: [Django] #20752: Error signals are not reliable, especially when dealing with database errors

[Django]

#20752: Error signals are not reliable, especially when dealing with database
errors
-+-
 Reporter:  tal@…|Owner:  schacki
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  signals errors   | Triage Stage:  Accepted
  databaseError  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ptone):

 * version:  1.5 => master
 * component:  Core (Other) => HTTP handling
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 I agree there is some room to improve the robustness of the handler here
 in the case of "something bad happened".

 Signal receiver's shouldn't be doing anything fancy when getting the
 "got_request_exception" signal (basically heeding the warning in the
 docstring of "handle_uncaught_exception", but the handler itself should be
 robust against any poorly written signal handler.

 Another related place the handler could be more robust is in
 "handle_uncaught_exception" itself. While hopefully rare, someone could
 have attempted to install some fancy 500 handler which itself raises some
 unforseen exceptoin - so maybe a try except is needed there as well, with
 some logging, and then returning a minimal 500 ala:

 {{{
 return http.HttpResponseServerError('Server Error (500)',
 content_type='text/html')
 }}}

 Also it is not clear to me why the more robust sending of the signal step
 shouldn't just be rolled into  handle_uncaught_exception. Those two steps
 occur together every single time in the handler, so I'm not sure why they
 need to be separate steps - sending the signal could easily be considered
 as "part of" handling the uncaught exception.

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

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

Re: [Django] #21295: Add on_update support

[Django]

#21295: Add on_update support
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

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


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

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

[Django] #21295: Add on_update support

[Django]

#21295: Add on_update support
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 There are cases where on-update cascade support would be useful. Currently
 Django offers no way to cascade updates.

 An experimental patch implementing on_update=models.CASCADE support for
 foreign keys is available from:
 https://github.com/akaariai/django/tree/update_cascade. It is based on
 composite foreign keys branch
 (https://github.com/akaariai/django/tree/soc2013/composite-fields).

 I'll attach a sample project to this ticket. Unpack it, use the above
 mentioned branch of Django, run syncdb, runserver and try in admin. Note
 that the country/city names are stored locally in the models, so country
 name update cascades to cities and from cities to streets.

-- 
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.1142f1b207a95c08abc602552578ad6e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19793: global name 'timezone' is not defined

[Django]

#19793: global name 'timezone' is not defined
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.5-alpha-1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  global name  | Triage Stage:
  'timezone' is not defined  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 I know this is an older thread.  I had the same problem because I forgot
 to add this line:
 from django.utils import timezone

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

[Django] #21294: Clarification of documentation logout next_page in GET

[Django]

#21294: Clarification of documentation logout next_page in GET
--+
 Reporter:  wim@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Currently, logout's documentation does not state clearly that the GET
 parameter for the redirect view is "next" by default.

 """Overrides next_page if the given GET parameter is passed.""" seems to
 imply the default name is "next_page", but actually it is "next".

 Current documentation:
 
https://docs.djangoproject.com/en/dev/topics/auth/default/#django.contrib.auth.views.logout

-- 
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/059.bda1bef25518ce1a2eebff14414b8071%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21286: Fix commented out tests in serializers_regress

[Django]

#21286: Fix commented out tests in serializers_regress
--+
 Reporter:  timo  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  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 bmispelon):

 * cc: bmispelon@… (added)


Comment:

 While looking into this, I believe I found the reason why some of the
 tests are commented:
 
https://github.com/django/django/blob/8d6953d55c3aba04bbaf0f268499d6e405c653ff/tests/serializers_regress/models.py#L168-L170


 The comment is not completely correct however because a few of the
 commented out models trigger and error immediately, regardless of the
 backend (`TypeError: 'primary_key' is not a valid argument for ...`).

 * `FilePKData`, `ImagePKData` and `NullBooleanPKData` can be deleted
 because of this.

 * `DatePKData`, `DateTimePKData`, `TimePKData` and `TextPKData` might be
 database-dependent (they all work under sqlite).

 * Test case 51 (`FileData`) might be worth looking into a bit deeper. It
 fails when uncommented and I believe it might be caused by the weird
 `FileField.__eq__` implementation.

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

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

Re: [Django] #21238: `ImageFieldFile.url` raises an AttributeError exception after retrieving it from cache

[Django]

#21238: `ImageFieldFile.url` raises an AttributeError exception after 
retrieving it
from cache
-+
 Reporter:  dulaccc  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  imagefield, cache| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by vajrasky):

 Here is the pull request (based on master/1.7) that can fix this problem:
 https://github.com/django/django/pull/1781

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

Re: [Django] #6668: Optimise utils.text wrap

[Django]

#6668: Optimise utils.text wrap
--+
 Reporter:  SmileyChris   |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by susan):

 * status:  assigned => new
 * owner:  susan =>


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