Re: [Django] #18616: New auth signal: user_login_failed

2012-07-17 Thread Django
#18616: New auth signal: user_login_failed
--+
 Reporter:  micolous  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by bradpitcher):

 * needs_docs:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17751: GenericIPAddressField allows an ipv6 address to start with a space

2012-07-17 Thread Django
#17751: GenericIPAddressField allows an ipv6 address to start with a space
-+-
 Reporter:  federico.capoano@…   |Owner:  Federico
 Type:  Bug  |  Capoano
Component:  Forms|   Status:  new
 Severity:  Normal   |  Version:
 Keywords:   |  1.4-beta-1
  GenericIPAddressField, ipv6|   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by net147):

 * cc: net147 (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17208: Dogfood class-based views in contrib.admin

2012-07-17 Thread Django
#17208: Dogfood class-based views in contrib.admin
-+-
 Reporter:  melinath |Owner:  julien
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  class-based views|  Needs documentation:  1
  admin  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by net147):

 * cc: net147 (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18306: Deferred models should automatically issue update_fields when saving

2012-07-17 Thread Django
#18306: Deferred models should automatically issue update_fields when saving
-+-
 Reporter:  akaariai |Owner:  akaariai
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 The problem I faced was that there were multiple places in models/query.py
 where the deferred_fields would need to be calculated. The original
 implementation didn't take into account select_related (where
 get_cached_row() can return deferred instances), and qs.raw(). These just
 work with the current implementation. In addition, there is no additional
 state bookkeeping which is always a bonus. One less place for bugs to hide
 :)

 If one wants to do dirty field state tracking, the solution is to use the
 model instance itself or it's state to keep the dirty field info, and then
 just overrider the .save() method and use update_fields in there for the
 dirty fields.

 BTW I have been wondering if we should allow 'pk' in the update_fields. If
 you say `"update_fields=['pk']"`, then the primary key will be updated as
 part of the query. I know there is no cascade support in Django, but one
 can always use custom db schemas and ON UPDATE CASCADE. Seems useful to
 me. But of course not this ticket's problem...

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18306: Deferred models should automatically issue update_fields when saving

2012-07-17 Thread Django
#18306: Deferred models should automatically issue update_fields when saving
-+-
 Reporter:  akaariai |Owner:  akaariai
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by niwi):

 I liked more the solution keeping not diferred fields on models
 ``_state``, but also I like this solution.

 Great 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[Django] #18645: Simplified filesizeformat

2012-07-17 Thread Django
#18645: Simplified filesizeformat
--+
 Reporter:  jerome.renard@…   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Template system   |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Hi,

 You will find attached a patch for the filesizeformat template filter.

 The patch removes all the multiplications and uses bit shifting instead.

 This simplifies the code and (hopefully) makes it easier to read.

 Not a major change at all, but just in case.

 'Hope that helps :)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18547: Django-admin.py makemessages should show a specific error message if the user hasn't installed gettext (e. g. on windows)

2012-07-17 Thread Django
#18547: Django-admin.py makemessages should show a specific error message if the
user hasn't installed gettext (e. g. on windows)
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Claude Paroz ):

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


Comment:

 In [8184aff2b0a3fbe6759163c0289f640a393a3e99]:
 {{{
 #!CommitTicketReference repository=""
 revision="8184aff2b0a3fbe6759163c0289f640a393a3e99"
 Fixed #18547 -- Improved error message when gettext is missing
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] 8184af: Fixed #18547 -- Improved error message when gettex...

2012-07-17 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8184aff2b0a3fbe6759163c0289f640a393a3e99
  
https://github.com/django/django/commit/8184aff2b0a3fbe6759163c0289f640a393a3e99
  Author: Claude Paroz 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/core/management/commands/makemessages.py

  Log Message:
  ---
  Fixed #18547 -- Improved error message when gettext is missing



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18561: HttpResponse.tell() fails if response contains non ascii characters

2012-07-17 Thread Django
#18561: HttpResponse.tell() fails if response contains non ascii characters
-+-
 Reporter:  matsevich.devel@…|Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  tell, HttpResponse,  | Triage Stage:  Accepted
  response   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [23f94f0741100233862922a8e77a3ac9dc1833e9]:
 {{{
 #!CommitTicketReference repository=""
 revision="23f94f0741100233862922a8e77a3ac9dc1833e9"
 Fixed #18561 -- Made HttpResponse.tell() support non-ascii chars
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] 23f94f: Fixed #18561 -- Made HttpResponse.tell() support n...

2012-07-17 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 23f94f0741100233862922a8e77a3ac9dc1833e9
  
https://github.com/django/django/commit/23f94f0741100233862922a8e77a3ac9dc1833e9
  Author: Claude Paroz 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/http/__init__.py
M tests/regressiontests/httpwrappers/tests.py

  Log Message:
  ---
  Fixed #18561 -- Made HttpResponse.tell() support non-ascii chars



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17600: Error in encapsulates filters (Q)

2012-07-17 Thread Django
#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 The https://github.com/akaariai/django/tree/refactor_utils_tree branch
 contains now the tests for this ticket. Everything works, except the
 double-subquery tests, which is added as an expected failure into the
 suite.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18639: manage.py shell should have a flag to explicitly request iPython or bpython

2012-07-17 Thread Django
#18639: manage.py shell should have a flag to explicitly request iPython or 
bpython
-+-
 Reporter:  Alex |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Alex):

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


Comment:

 Merged in
 
https://github.com/django/django/commit/110c72930948a8853acfce0ab747247a06a935f7

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #11293: Filters on aggregates lose connector

2012-07-17 Thread Django
#11293: Filters on aggregates lose connector
-+-
 Reporter:  django@… |Owner:  -
 Type:  Bug  |   Status:  reopened
Component:  ORM aggregation  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  having, where,   | Triage Stage:  Accepted
  aggregate, connector   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 There was an error in the branch - the branch splits q_objects to multiple
 different trees for having - where clause separation
 (find_having_splits()) in the branch. This made in-place modifications to
 the given q_object and this was the cause of the error. I made a change
 where the q_object is used as-is in the query, except when it contains
 references to aggregates, in which case it is first deepcopied, and only
 then splitted to parts.

 I have updated the
 https://github.com/akaariai/django/tree/refactor_utils_tree branch to
 contain a fix for 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

2012-07-17 Thread Django
#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  sfllaw
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by sfllaw):

 It'd be great to get a core developer to look at whether the suggested
 refactoring above would be sensible.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] f2abfe: Adds interpreter option to shell command as per ti...

2012-07-17 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f2abfe1e4853df1848d178c3de369c80932292e8
  
https://github.com/django/django/commit/f2abfe1e4853df1848d178c3de369c80932292e8
  Author: Mike Grouchy 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/core/management/commands/shell.py
M docs/ref/django-admin.txt

  Log Message:
  ---
  Adds interpreter option to shell command as per ticket #18639

Specify python interpreter interface ipython or bpython with the -i,
--interface options
argument.
 ex// python manage.py shell -i bpython
 ex// python manage.py shell --interface bpython

Like all other options, defaults to default python interpreter when your
selected choice isn't available.

updated documentation where appropriate


  Commit: 110c72930948a8853acfce0ab747247a06a935f7
  
https://github.com/django/django/commit/110c72930948a8853acfce0ab747247a06a935f7
  Author: Alex Gaynor 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/core/management/commands/shell.py
M docs/ref/django-admin.txt

  Log Message:
  ---
  Merge pull request #215 from mgrouchy/add-interpreter-options

Adds interpreter option to shell command as per ticket #18639


Compare: https://github.com/django/django/compare/52df0d50b0d9...110c72930948

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

2012-07-17 Thread Django
#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  sfllaw
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Not anything I spotted immediately. As said, I haven't gone through this
 in full detail. If you can get somebody to review the patch it would of
 course be a plus.

 I will try to get time to work on this. I can't promise anything, though.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #8892: ForeignKey relation not saved as expected

2012-07-17 Thread Django
#8892: ForeignKey relation not saved as expected
-+-
 Reporter:  julien   |Owner:
 Type:  Bug  |  blacklwhite
Component:  Database layer   |   Status:  reopened
  (models, ORM)  |  Version:  1.0
 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
-+-

Comment (by akaariai):

 I wonder if the set is the proper place to raise the error. One could
 construct model instances without ever saving them. Isn't the error really
 happening at save time?

 The check would be to go though foreign key fields in model.save(). If the
 instance's `__dict__` contains a model for the foreign key field's name,
 but the value for field.attname in self.`__dict__` is missing or is None,
 then raise an error.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

2012-07-17 Thread Django
#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  sfllaw
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by sfllaw):

 akaariai: Are there any improvements to this patch that you can suggest?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #7760: Queries on large primary tables with limit/offset clauses are slow

2012-07-17 Thread Django
#7760: Queries on large primary tables with limit/offset clauses are slow
-+-
 Reporter:  henrybaxter  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
  database,admin,slow,query  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 I think this can be closed. First, to me it seems a good DB would be able
 to optimize such queries, second, I am afraid supporting this will be
 hard. I wonder if fixing this ticket would cause performance problems for
 other queries.

 If we want to support this kind of query, then I think a separate API for
 doing subqueries would be the way to go.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #7140: Errors in escaping fieldnames in Oracle

2012-07-17 Thread Django
#7140: Errors in escaping fieldnames in Oracle
-+-
 Reporter:  herwin@… |Owner:  mboersma
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  qsrf-cleanup |  Needs documentation:  0
  oracle, quote, escape  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 Im going to close this one. One can already use db_table =
 '"SOME_SCHEMA.SOME_TABLE"' if they want to. This ticket asks to allow
 usage of 'SOME_SCHEMA.SOME_TABLE'. No point in my opinion.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

2012-07-17 Thread Django
#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  sfllaw
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I haven't tested this ticket, just skimmed the latest patch. To me it
 seems this is worth getting into Django, the savings can be pretty large
 if one regularly does small changes to m2m fields using list assignment.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #5063: PostgreSQL connection close when using model with a OneToOneField and a ManyToManyField

2012-07-17 Thread Django
#5063: PostgreSQL connection close when using model with a  OneToOneField and a
ManyToManyField
-+-
 Reporter:  John Shaffer |Owner:  nobody
 |   Status:  closed
 Type:  Bug  |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 I don't believe this to be an issue any longer. We would have heard more
 of this if this were still an 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #3148: Add getters and setters to model fields

2012-07-17 Thread Django
#3148: Add getters and setters to model fields
-+-
 Reporter:  jerf@…   |Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I have a feeling this ticket needs to be wontfixed. The reason is that it
 seems the setter should not be called in model.`__init__` if the object
 comes from the DB. On the other hand, `__setattr__` must be called for
 backwards compatibility reasons. I don't see how to achieve this: you
 can't assign to the attribute in `__init__` - setter will not be called.
 You can't assign to `__dict__` - setattr will not be called. In addition
 the solution must not cause any severe performance regressions to
 `__init__`

 We have managed to live without this feature to this day. Maybe it is time
 to just let this feature go?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18644: django.util.html.urlize fails to trim trailing period when followed by a parenthesis

2012-07-17 Thread Django
#18644: django.util.html.urlize fails to trim trailing period when followed by a
parenthesis
-+-
 Reporter:  ljosa|Owner:  ljosa
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by ljosa):

 [https://github.com/django/django/pull/216#commits-pushed-d5012d6 Moved
 the test] in accordance with
 [https://github.com/django/django/pull/216#issuecomment-7040824 claudep's
 comment].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18644: django.util.html.urlize fails to trim trailing period when followed by a parenthesis

2012-07-17 Thread Django
#18644: django.util.html.urlize fails to trim trailing period when followed by a
parenthesis
-+-
 Reporter:  ljosa|Owner:  ljosa
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Unreviewed => Ready for checkin


Comment:

 To me the patch looks good, and the use case valid. Marking as ready for
 checkin. I will wait a while for comments before committing 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18644: django.util.html.urlize fails to trim trailing period when followed by a parenthesis

2012-07-17 Thread Django
#18644: django.util.html.urlize fails to trim trailing period when followed by a
parenthesis
-+--
 Reporter:  ljosa|Owner:  ljosa
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by akaariai):

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


Comment:

 The ticket should not be closed until the patch gets committed into
 Django.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18616: New auth signal: user_login_failed

2012-07-17 Thread Django
#18616: New auth signal: user_login_failed
--+
 Reporter:  micolous  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by bradpitcher):

 Thanks for the catch. I updated the documentation for the sender parameter
 in https://github.com/brad/django/tree/ticket_18616_docs

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18644: django.util.html.urlize fails to trim trailing period when followed by a parenthesis

2012-07-17 Thread Django
#18644: django.util.html.urlize fails to trim trailing period when followed by a
parenthesis
-+--
 Reporter:  ljosa|Owner:  ljosa
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by ljosa):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * resolution:   => fixed


Comment:

 Fixed in [https://github.com/django/django/pull/216 Pull request 216]. I
 also added a regression test.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[Django] #18644: django.util.html.urlize fails to trim trailing period when followed by a parenthesis

2012-07-17 Thread Django
#18644: django.util.html.urlize fails to trim trailing period when followed by a
parenthesis
-+
 Reporter:  ljosa|  Owner:  ljosa
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+
 Users would probably expect

 {{{
 django.utils.html.urlize('(Go to http://www.example.com/foo.)')
 }}}

 to produce

 {{{
 u'(Go to http://www.ljosa.priv.no/foo";>http://www.ljosa.priv.no/foo.)'
 }}}

 and not

 {{{
 u'(Go to http://www.ljosa.priv.no/foo.";>http://www.ljosa.priv.no/foo.)'
 }}}

 as it does at present.

 The fix should be easy; I expect to submit a pull request soon.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[Django] #18643: untitled

2012-07-17 Thread Django
#18643: untitled
---+
 Reporter:  guest  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 [http://www.sepwatches.org/japanese-replica-watches-replica-
 bvlgari-c-8_17.html Bvlgari replica] looks gorgeous in a colorful dress,
 the [http://www.sepwatches.org/japanese-replica-watches-rolex-replica-
 watches-c-8_14.html rolex replica] features large space with double
 handles and a detachable strap.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] 52df0d: Switched to use a more idiomatic construct.

2012-07-17 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 52df0d50b0d903c8d845404b8da89b174f8824cc
  
https://github.com/django/django/commit/52df0d50b0d903c8d845404b8da89b174f8824cc
  Author: Alex Gaynor 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/db/models/sql/query.py

  Log Message:
  ---
  Switched to use a more idiomatic construct.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[Django] #18642: Pointer to django.shortcuts.render

2012-07-17 Thread Django
#18642: Pointer to django.shortcuts.render
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Hi,

 I wish the documentation would point to
 [https://docs.djangoproject.com/en/1.4/topics/http/shortcuts/#render] from
 the relevant Note section in
 
https://docs.djangoproject.com/en/1.4/ref/templates/api/#django.template.RequestContext,
 rather than suggesting that I'm stuck with having to pass
 "context_instance=RequestContext(request)" to each render_to_response
 which I want to have TEMPLATE_CONTEXT_PROCESSORS (ie all of them).

 Many 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18501: Custom fields as foreign keys fix

2012-07-17 Thread Django
#18501: Custom fields as foreign keys fix
-+-
 Reporter:  msopacua |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  RelatedField |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by msopacua):

 Ok, so I'm unable to write a proper test case, because the ModelForm class
 does not expose the bug but the admin change form does. So the admin does
 something special, that I'm unable to figure out that exposes this bug.

 Therefore I've provided an app "devices", that is a copy of the models
 involved reduced to the size that they still expose the bug. The test case
 therein as said, works properly. However, if one adds 'devices' to the
 installed apps of a project, load the fixture and then browse to
 http://localhost/admin/devices/devicepciid/1/ you will see that the vendor
 is not selected. Applying the patch, reloading application and refreshing
 the browser will show that the vendor is selected. I suspect the formfield
 callback to be the culprit but can't really figure out how to make this
 into a proper test case.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17788: bulk_create() "too many SQL variables" error

2012-07-17 Thread Django
#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  akaariai
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * status:  closed => reopened
 * version:  1.4-beta-1 => 1.4
 * resolution:  fixed =>
 * severity:  Normal => Release blocker


Comment:

 I have created a backpatch of the committed fix in
 https://github.com/akaariai/django/tree/ticket_17788_backpatch.

 I will wait for last comments about the backpatch before proceeding with
 the backpatch. I am little less enthusiastic of backpatching this than
 before, but I think I am still going to do it as that was the decision
 some time ago.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17788: bulk_create() "too many SQL variables" error

2012-07-17 Thread Django
#17788: bulk_create() "too many SQL variables" error
-+-
 Reporter:  alpar|Owner:  akaariai
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Normal   |   Resolution:  fixed
 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
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [29132ebdef0e0b9c09e456b05f0e6a22f1106a4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="29132ebdef0e0b9c09e456b05f0e6a22f1106a4f"
 Fixed #17788 -- Added batch_size argument to qs.bulk_create()

 The qs.bulk_create() method did not work with large batches together
 with SQLite3. This commit adds a way to split the bulk into smaller
 batches. The default batch size is unlimited except for SQLite3 where
 the batch size is limited to 999 SQL parameters per batch.

 Thanks to everybody who participated in the discussions at Trac.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] 29132e: Fixed #17788 -- Added batch_size argument to qs.bu...

2012-07-17 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 29132ebdef0e0b9c09e456b05f0e6a22f1106a4f
  
https://github.com/django/django/commit/29132ebdef0e0b9c09e456b05f0e6a22f1106a4f
  Author: Anssi Kääriäinen 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/sqlite3/base.py
M django/db/models/query.py
M docs/ref/models/querysets.txt
M docs/releases/1.5.txt
M tests/regressiontests/bulk_create/models.py
M tests/regressiontests/bulk_create/tests.py
M tests/regressiontests/queries/tests.py

  Log Message:
  ---
  Fixed #17788 -- Added batch_size argument to qs.bulk_create()

The qs.bulk_create() method did not work with large batches together
with SQLite3. This commit adds a way to split the bulk into smaller
batches. The default batch size is unlimited except for SQLite3 where
the batch size is limited to 999 SQL parameters per batch.

Thanks to everybody who participated in the discussions at Trac.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18639: manage.py shell should have a flag to explicitly request iPython or bpython

2012-07-17 Thread Django
#18639: manage.py shell should have a flag to explicitly request iPython or 
bpython
-+-
 Reporter:  Alex |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by mgrouchy):

 Replying to [comment:2 jezdez]:
 > Please don't use "`--interp`" but "`-i`" and "`--interface`" (just
 provide them after each other). "Interpreter" is misleading as the switch
 doesn't switch the actual interpreter you're running the Python files
 with.

 Sure, I will make that change today. I thought while --interp may be less
 correct technically most people refer to bpython and iPython as python
 interpreters(Even though they are both just interfaces to the interpreter)
 so it seemed like a nicer UI.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #17497: Confusing exception message when using values_list with relations

2012-07-17 Thread Django
#17497: Confusing exception message when using values_list with relations
-+-
 Reporter:  ojii |Owner:
 Type:   |  antoviaque
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [fcad6c48f07bdc6346c065849a87f0f02afb6f94]:
 {{{
 #!CommitTicketReference repository=""
 revision="fcad6c48f07bdc6346c065849a87f0f02afb6f94"
 Fixed #17497 -- Corrected FieldError message in add_fields()

 The erroneous message was user visible in values_list() calls.

 Thanks to ojii for report and review, and to antoviaque for the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[django/django] fcad6c: Fixed #17497 -- Corrected FieldError message in ad...

2012-07-17 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fcad6c48f07bdc6346c065849a87f0f02afb6f94
  
https://github.com/django/django/commit/fcad6c48f07bdc6346c065849a87f0f02afb6f94
  Author: Anssi Kääriäinen 
  Date:   2012-07-17 (Tue, 17 Jul 2012)

  Changed paths:
M django/db/models/sql/query.py
M tests/modeltests/many_to_one/tests.py

  Log Message:
  ---
  Fixed #17497 -- Corrected FieldError message in add_fields()

The erroneous message was user visible in values_list() calls.

Thanks to ojii for report and review, and to antoviaque for the patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18640: django.contrib.gis.gdal.DataSource fields give gibberish or segfault when accessed directly

2012-07-17 Thread Django
#18640: django.contrib.gis.gdal.DataSource fields give gibberish or segfault 
when
accessed directly
-+
 Reporter:  YenTheFirst  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.4
 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 claudep):

 * needs_better_patch:   => 0
 * component:  Uncategorized => GIS
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Confirmed. It appears that it is the same type of issue as in #9448. At
 least, adding references to parent objects seems to solve the problem.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18639: manage.py shell should have a flag to explicitly request iPython or bpython

2012-07-17 Thread Django
#18639: manage.py shell should have a flag to explicitly request iPython or 
bpython
-+-
 Reporter:  Alex |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by jezdez):

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


Comment:

 Please don't use "`--interp`" but "`-i`" and "`--interface`" (just provide
 them after each other). "Interpreter" is misleading as the switch doesn't
 switch the actual interpreter you're running the Python files with.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18637: FK.limit_choices_to doc says it's for admin, but works in ModelForm

2012-07-17 Thread Django
#18637: FK.limit_choices_to doc says it's for admin, but works in ModelForm
---+
 Reporter:  Tuttle |Owner:  nobody
 Type:  Bug|   Status:  new
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:  1  |UI/UX:  0
---+

Comment (by claudep):

 It appears that on that page, there are multiple references to admin as a
 synonym for `ModelForm`.

 For example, "The admin represents this as an ".
 Shouldn't this read as "The default form widget for this field is a
 `TextInput`."?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [Django] #18634: Escaping in the startproject command

2012-07-17 Thread Django
#18634: Escaping in the startproject command
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mjtamlyn):

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


Comment:

 See Pull Request here: https://github.com/django/django/pull/214

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.