Re: [Django] #13252: Use the natural key instead of the primary key when serializing

[Django]

#13252: Use the natural key instead of the primary key when serializing
-+-
 Reporter:  SmileyChris  |Owner:
 Type:  New feature  |  mtredinnick
Component:  Core |   Status:  reopened
  (Serialization)|  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
-+-

Comment (by charettes):

 FWIW all tests pass on python 2.7.3rc1 sqlite3. I guess the backward
 compatibility or ''must opt-in'' issue SmileyChris was referring to is no
 more with two new flags?

-- 
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] #18004: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.

[Django]

#18004: Django should not use `force_unicode(..., errors='replace')` when 
parsing
POST data.
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  post data unicode| Triage Stage:  Design
  utf8 encode decode transaction |  decision needed
  aborted|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mrmachine):

 I've updated this patch on a branch at GitHub to apply cleanly.

 https://github.com/thirstydigital/django/tree/tickets/18004
 -multipartparser-force_unicode

 Can we get a BDFL decision here?

 Would people prefer to see an alternative patch where Django *tries* to
 decode it with errors='strict' first, and adds a dirty flag to
 request.POST and request.FILES (indicating which field names, field data,
 file names or file field names are "dirty") if the data cannot be cleanly
 decoded, so that developers can choose how to handle it in their view,
 e.g. return a form validation error, instead of an HTTP 500 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] #16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid literal for int() with base 10`

[Django]

#16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid 
literal
for int() with base 10`
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  ORM aggregation  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  annotate | Triage Stage:  Accepted
  select_related only defer  |  Needs documentation:  0
  ValueError empty list  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mrmachine):

 I've updated this patch on a branch at GitHub to apply cleanly.

 https://github.com/thirstydigital/django/tree/tickets/16436-annotate-
 select_related-only

 I think this is RFC. Does anyone have feedback or issues that would
 prevent this from being committed?

-- 
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] #14694: defer() doesn't work with reverse relations

[Django]

#14694: defer() doesn't work with reverse relations
-+-
 Reporter:  sayane   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  defer only   |  Needs documentation:  0
  OneToOneField reverse  |  Patch needs improvement:  1
  relationship   |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by mrmachine):

 * cc: real.human@… (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] #14694: defer() doesn't work with reverse relations

[Django]

#14694: defer() doesn't work with reverse relations
-+-
 Reporter:  sayane   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  defer only   |  Needs documentation:  0
  OneToOneField reverse  |  Patch needs improvement:  1
  relationship   |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mrmachine):

 I've updated this patch on a branch at GitHub to apply cleanly again.

 https://github.com/thirstydigital/django/tree/tickets/14694-defer-reverse-
 relations

 I don't think there is a problem with the `opts =
 opts.proxy_for_model._meta` line that you questioned.

 In the case of an automatic proxy model with deferred fields, we are
 intentionally accessing the opts from the concrete model in order to get
 and populate non-local fields correctly. Those fields don't exist on the
 automatic proxy model. We can only get them from the concrete model.

 I still think this patch is RFC, and that this is a clear bug. Maybe you
 can improve the test cases to confirm your suspicions (or confirm that the
 patch is good)?

-- 
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] #13252: Use the natural key instead of the primary key when serializing

[Django]

#13252: Use the natural key instead of the primary key when serializing
-+-
 Reporter:  SmileyChris  |Owner:
 Type:  New feature  |  mtredinnick
Component:  Core |   Status:  reopened
  (Serialization)|  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
-+-

Comment (by mrmachine):

 I've updated this patch again on a branch at GitHub.

 https://github.com/thirstydigital/django/tree/tickets/13252-natural-key-
 serializing

 SmileyChris, can you elaborate on making the new behaviour optional?
 Unless I'm missing something, it is? The `--natural` option maps to
 `--natural-foreign` (which behaves the same, with a pending deprecation
 warning) and we now have a new `--natural-primary` option as well.

 I believe I've incorporated all the changes russellm requested and this
 should be RFC now.

-- 
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] #7231: New "join" parameter for the "extra" QuerySet method

[Django]

#7231: New "join" parameter for the "extra" QuerySet method
-+-
 Reporter:  Davide "Design"  |Owner:  nobody
  Muzzarelli |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  queryset extra left  |  Needs documentation:  1
  join   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by mrmachine):

 * cc: real.human@… (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.

[Django] #18693: Minor bug in tutorial part 3

[Django]

#18693: Minor bug in tutorial part 3
---+
 Reporter:  mpwoodward |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Brand new to Django and I'm going through your excellent tutorial, and
 unless I missed a step there is a small bug in the code in part 3 of the
 tutorial here:
 https://docs.djangoproject.com/en/1.4/intro/tutorial03/

 Specifically, this chunk under the heading "Use the template system":
 {{{
 {{ poll.question }}
 
 {% for choice in poll.choice_set.all %}
 {{ choice.choice }}
 {% endfor %}
 
 }}}
 Unless I'm mistaken in the loop it should be choice.choice_text instead of
 choice.choice. When I changed it to choice.choice_text the choice text
 appeared in the output.

-- 
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] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

[Django]

#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
 Reporter:  mrmachine|Owner:  ccahoon
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  stream HttpResponse  | Triage Stage:  Accepted
  Content-Length |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mrmachine):

 I've updated this patch on a branch at GitHub.

 https://github.com/thirstydigital/django/tree/tickets/7581-streaming-
 response-middleware

 If somebody can provide some concrete direction on the desired approach to
 resolve this (BDFL decision?), I'll try to add docs and tests as well.

 FYI, I've been using this patch in various incarnations for 4 years in
 production environments without any problems.

 My vote is still for allowing middleware to ask the response if it is
 streaming (generator as content) or not, and act accordingly. Either by
 changing their behaviour (to be compatible with streaming responses),
 doing nothing (to avoid breaking a streaming response), or forcing the
 response to consume the content (breaking the streaming response, but
 ensuring that the middleware always runs).

-- 
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] #18685: Managements commands in multiple submodules in the same virtual package don't work

[Django]

#18685: Managements commands in multiple submodules in the same virtual package
don't work
-+-
 Reporter:  cberner  |Owner:  cberner
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by bhuztez):

 This is a duplicate of #14087.

 for namespace package, you can try my patch:
 https://github.com/django/django/pull/178

-- 
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] #7231: New "join" parameter for the "extra" QuerySet method

[Django]

#7231: New "join" parameter for the "extra" QuerySet method
-+-
 Reporter:  Davide "Design"  |Owner:  nobody
  Muzzarelli |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  queryset extra left  |  Needs documentation:  1
  join   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by mrmachine):

 If anyone else wants or needs this functionality, I've updated the patch
 on a branch at GitHub. I'll try to keep it updated periodically as long as
 I'm still using it myself.

 https://github.com/thirstydigital/django/tree/tickets/7231-extra-join

-- 
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] #18494: Positional arguments not passed to view functions in included urlconfs

[Django]

#18494: Positional arguments not passed to view functions in included urlconfs
---+
 Reporter:  rfugger|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Core (URLs)|  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  urls, urlconf  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by SmileyChris):

 * status:  new => closed
 * type:  Bug => New feature
 * resolution:   => wontfix


Comment:

 This is not a bug -- the docs specifically cover the current behaviour:
 https://docs.djangoproject.com/en/1.4/topics/http/urls/#the-matching-
 grouping-algorithm.

 I can't see how we could introduce this without being backwards
 incompatible (someone may be using a mix and expecting the conf to ignore
 the unnamed groups).

-- 
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] #18678: HTTPResponse subclasses don't accept base class parameters

[Django]

#18678: HTTPResponse subclasses don't accept base class parameters
---+--
 Reporter:  hp1337@…   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.3
 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 ptone):

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


Comment:

 Can you provide more detail about your use case - while I can't find
 anything in a quick review of the spec that prohibits setting a content-
 type for a 405 response, it is hard to imagine a client that would do
 something specific with it.

 If this is in fact something that should be supported - it should be
 supported for most (all?) included subclasses of HttpResponse.

-- 
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] #18690: Typo in Testing documentation response.context

[Django]

#18690: Typo in Testing documentation response.context
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords:  typo, testing  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ptone):

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


Comment:

 The response returned by a test client is not the same class of object as
 a TemplateResponse object, which does have the context_data attribute.
 I'm assuming you have these confused - as the test client is documented
 properly.

-- 
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] #13693: error_messages for fields in Model don't carry over to ModelForm

[Django]

#13693: error_messages for fields in Model don't carry over to ModelForm
-+-
 Reporter:  Aleks|Owner:  anonymous
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  error_messages,  |  worksforme
  forms, models  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by colegatron):

 * status:  reopened => closed
 * resolution:   => worksforme
 * needs_tests:  0 => 1
 * version:  1.2 => 1.4
 * needs_docs:  0 => 1
 * type:  Uncategorized => New feature


Comment:

 I am new to Django but I also think the DRY mantra should be aplicable to
 the error_messages inheritance from the model to the modelform.
 Perhaps by a design point of view it is not a good idea, as points Honza
 in his first comment (22 months ago), but to redefine all the fields in
 the modelform or form classes to get the error_messages (and perhaps other
 attributes) is tedious and boilerplate.
 Looking for a way to avoid this, I have find a post
 (http://blog.brendel.com/2012/01/django-modelforms-setting-any-field.html)
 which gives a very nice, easy and elegant way to do it.

 Probably that solution can be improved, but in my opinion is candidate to
 be imported as new feature in the base modelform class:

 Example of use:

 {{{
 class AuthorForm(ExtendedMetaModelForm):
 class Meta:
 model = Author
 field_args = {
 "first_name" : {
 "error_messages" : {
 "required" : "Please let us know what to call you!"
 }
 },
 "notes" : {
 "+error_messages" : {
 "required" : "Please also enter some notes.",
 "invalid"  : "This is not a valid note."
 },
 "widget" : forms.Textarea(attrs={'cols': 70, 'rows': 15}),
 }
 }
 }}}

 Extended modelform class:

 {{{
 class ExtendedMetaModelForm(forms.ModelForm):
 """
 Allow the setting of any field attributes via the Meta class.
 """
 def __init__(self, *args, **kwargs):
 """
 Iterate over fields, set attributes from Meta.field_args.
 """
 super(ExtendedMetaModelForm, self).__init__(*args, **kwargs)
 if hasattr(self.Meta, "field_args"):
 # Look at the field_args Meta class attribute to get
 # any (additional) attributes we should set for a field.
 field_args = self.Meta.field_args
 # Iterate over all fields...
 for fname, field in self.fields.items():
 # Check if we have something for that field in field_args
 fargs = field_args.get(fname)
 if fargs:
 # Iterate over all attributes for a field that we
 # have specified in field_args
 for attr_name, attr_val in fargs.items():
 if attr_name.startswith("+"):
 merge_attempt = True
 attr_name = attr_name[1:]
 else:
 merge_attempt = False
 orig_attr_val = getattr(field, attr_name, None)
 if orig_attr_val and merge_attempt and \
 type(orig_attr_val) == dict and \
 type(attr_val) == dict:
 # Merge dictionaries together
 orig_attr_val.update(attr_val)
 else:
 # Replace existing attribute
 setattr(field, attr_name, attr_val)

 }}}


 Hope this two years ticket can be closed with that nice solution.

-- 
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] #18692: Django 1.3.2 breaks Python 2.4 compatibility

[Django]

#18692: Django 1.3.2 breaks Python 2.4 compatibility
---+
 Reporter:  chipx86|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The recent URL scheme restriction change assumes Python 2.5+ accessors for
 the parsed URI information. Specifically, it's looking up parsed.scheme,
 which isn't available in Python 2.4. Instead, it should be accessing it as
 a tuple.

 The traceback below shows what's happening.

 {{{
 Traceback (most recent call last):
   File "/usr/lib/python2.4/site-
 packages/Django-1.3.2-py2.4.egg/django/core/handlers/base.py", line 111,
 in get_response
 response = callback(request, *callback_args, **callback_kwargs)
   File "/usr/lib/python2.4/site-
 packages/Django-1.3.2-py2.4.egg/django/views/generic/simple.py", line 57,
 in redirect_to
 return klass(url % kwargs)
   File "/usr/lib/python2.4/site-
 packages/Django-1.3.2-py2.4.egg/django/http/__init__.py", line 645, in
 __init__
 if parsed.scheme and parsed.scheme not in self.allowed_schemes:
 AttributeError: 'tuple' object has no attribute 'scheme'
 }}}

-- 
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] #18686: Models with same name and common subpackage name clash

[Django]

#18686: Models with same name and common subpackage name clash
-+-
 Reporter:  jason.yates@…|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ptone):

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


Comment:

 This is a result of the models being associated with an implicit app_label
 that is derived from the path to the model.

 because the app label namespace is flat, a subsequent attempt to import a
 model named "test" for an app with the label "test" will first check the
 appcache and return an existing model matching that pair of identifiers.
 This is a case of clashing app names/labels and as such is a duplicate of
 #3591

 The real bug here is that no error is raised (in Django 1.4) with the
 following in installed_apps:

 {{{
 'base.a.miscapp',
 'base.b.miscapp',
 ...
 }}}

 this results in two applications with the same label - which will confound
 the model registration process - such a case should raise an error
 pointing out the collision early on.

-- 
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] #18691: No timezone support for TimeField

[Django]

#18691: No timezone support for TimeField
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  timezone, datetime,  |  Unreviewed
  datetimefield, timefield   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by tejinderss@…):

 Ok i will have a look, thanks a lot.

-- 
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] #18603: Adding support for PEP 302 importers

[Django]

#18603: Adding support for PEP 302 importers
--+
 Reporter:  bhuztez   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Uncategorized |  Version:
 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 cberner):

 * cc: cberner (added)


Comment:

 Hey bhuztez,

 I started work on part of this (the management command issue) because
 we've run into it. My patch is
 [https://github.com/cberner/django/tree/issue18685 here]. Let me know if I
 can be of assistance with other parts of 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 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] #18691: No timezone support for TimeField

[Django]

#18691: No timezone support for TimeField
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  timezone, datetime,  |  Unreviewed
  datetimefield, timefield   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Here's how aware-datetime support was added `DateTimeField`:
 https://github.com/django/django/commit/9b1cb755a2#L14L735

 You must do similar changes in a custom `TimeField`. You can either
 inherit Django's `TimeField` and override a few methods or copy its
 definition and edit it -- I don't know which way will look more clean.

-- 
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] #18691: No timezone support for TimeField

[Django]

#18691: No timezone support for TimeField
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  timezone, datetime,  |  Unreviewed
  datetimefield, timefield   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by tejinderss@…):

 Thanks for the quick response, could you please point me to the direction
 where i could get a help with AwareTimeField

-- 
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] #18691: No timezone support for TimeField

[Django]

#18691: No timezone support for TimeField
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  timezone, datetime,  |  Unreviewed
  datetimefield, timefield   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 This is a design decision and it's explained in the documentation. In
 short aware time objects are pathological creatures :)

 It is fairly easy to create a custom AwareTimeField if you need it.

-- 
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] #18691: No timezone support for TimeField

[Django]

#18691: No timezone support for TimeField
-+-
 Reporter:  tejinderss@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.4
  (models, ORM)  |   Keywords:  timezone, datetime,
 Severity:  Normal   |  datetimefield, timefield
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Django 1.4 does not store aware times for TimeField, it only does for
 DateTimeField. Its really annoying, as python datetime.time object does
 support TZINFO just like datetime.datetime objects.
 Steps to reproduce:
 In the view i have set the timezone to timezone.activate(timezone) and
 after that i used form's TimeInput field to get the time. Now when i store
 it, it does not make the conversion from the current timezone to default
 timezone (which is set to UTC), it just naive time object. If i follow the
 same steps with DateTimeField, it works as expected, the datetime is first
 converted from current timezone to default one and then stored to the db.

 Db used:
 Postgres 9.1 with psycopg2 adapter

-- 
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] #14930: `values_list()` fails on queryset ordered by extra column

[Django]

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  simon29
 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:  1|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by akaariai):

 The patch doesn't contain tests.

-- 
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] #18685: Managements commands in multiple submodules in the same virtual package don't work

[Django]

#18685: Managements commands in multiple submodules in the same virtual package
don't work
-+-
 Reporter:  cberner  |Owner:  cberner
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jezdez):

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


Comment:

 Duplicate of #18603 which has a more complete 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.

Re: [Django] #18685: Managements commands in multiple submodules in the same virtual package don't work

[Django]

#18685: Managements commands in multiple submodules in the same virtual package
don't work
-+-
 Reporter:  cberner  |Owner:  cberner
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ptone):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I've verified the attached bug demonstration - the fix looks good as
 pkgutil is more informed about package imports

 however testing this is hard - I did some experiments with creating a test
 local site-packages-like folder with the .egg-link files with relative
 paths, but didn't work on my first try.

 Current tests not working as implemented

 link to patch above is stale as it was to a single commit - pull request
 is here https://github.com/django/django/pull/240/files

-- 
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] #14930: `values_list()` fails on queryset ordered by extra column

[Django]

#14930: `values_list()` fails on queryset ordered by extra column
-+-
 Reporter:  lsaffre  |Owner:  simon29
 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:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by lau):

 * cc: lau@… (added)


Comment:

 Just hit this problem. Why hasn't the patch been pulled in?

-- 
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] #18690: Typo in Testing documentation response.context

[Django]

#18690: Typo in Testing documentation response.context
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:  typo, testing
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 Here
 
https://docs.djangoproject.com/en/1.3/topics/testing/#django.test.client.Response.context

 response.context should be response.context_data to access attributes in
 this way

-- 
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] #18404: SuspiciousOperation exception is thrown if application static path contains non-ascii characters

[Django]

#18404: SuspiciousOperation exception is thrown if application static path 
contains
non-ascii characters
-+-
 Reporter:  andkit@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by msopacua):

 * cc: m.r.sopacua@… (added)


Comment:

 Replying to [comment:4 aaugustin]:

 > Apparently my terminal (under OS X) doesn't support `export
 LC_ALL=fr_FR.ISO-8859-1`; that activates the C locale instead.

 That's cause on FreeBSD derived systems the locale would be
 fr_FR.ISO8859-1.

 The root cause is that u umlaut in latin-1 conflicts with UTF-8 encoding,
 where the value is used as part of the variable size encoding scheme:
 {{{
 >>> u = unicode('\xfc', 'latin1')
 >>> u.encode('utf-8')
 '\xc3\xbc'
 }}}

-- 
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] #18689: Error in code example

[Django]

#18689: Error in code example
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 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 aaugustin):

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


Comment:

 Duplicate of at least a dozen other tickets -- you aren't reading the docs
 for the version of Django you're using.

-- 
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] #18689: Error in code example

[Django]

#18689: Error in code example
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 At the bottom of part 3 of the tutorial
 (https://docs.djangoproject.com/en/dev/intro/tutorial03/) the code
 snippet:
 {{{
 {{ poll.question
 }}
 }}}
 generates a "No Reverse Match" error.
 Removing the single quotes around polls.views.detail fixes the problem:
 {{{
 {{ poll.question
 }}
 }}}

-- 
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] #12728: loadata/flush issues given GenericRelation, model inheritance and postgres

[Django]

#12728: loadata/flush issues given GenericRelation, model inheritance and 
postgres
-+-
 Reporter:  pragmar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  contrib.contenttypes   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
  psycopg2.ProgrammingError, |  Patch needs improvement:  0
  GenericRelation|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by lorinh):

 * cc: lorin@… (added)
 * needs_tests:  1 => 0


Comment:

 I added a failing test case by
 
[https://github.com/nimbis/django/commit/41c0a33bdabd567159da96626a6e5373691cacca
 modifying one of the existing test models] so that the
 backends.!SequenceResetTest will now fail unless the patch is applied.

-- 
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] #18688: Broken link on Download page

[Django]

#18688: Broken link on Download page
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Djangoproject.com|  Version:  1.4
  Web site   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Fixed (31 instead of 30 in the URL). 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.

[Django] #18688: Broken link on Download page

[Django]

#18688: Broken link on Download page
+
 Reporter:  anonymous   |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Djangoproject.com Web site  |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 On the down load page, https://www.djangoproject.com/download/, navigating
 to the link "release
 notes"|https://www.djangoproject.com/weblog/2012/jul/31/security-releases-
 issued/ gives page not found.

-- 
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] #18687: Randomly failing test: test_performance_scalability

[Django]

#18687: Randomly failing test: test_performance_scalability
-+
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  master
 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 akaariai):

 We should probably test something else than the proportion of total
 runtime.

 I think the underlying problem is that we are testing on a machine which
 is doing a lot of other tests at the same time. This can result in spikes
 in the testing times, and these lead to false positives. The problem is
 not imprecise measurement, it is that the runtime of the same code is not
 guaranteed to stay the same between consecutive runs.

 So, maybe doing 9 significantly shorter runs for iterations in alternating
 fashion and then comparing the median would work better? In code something
 like:
 {{{
 n1 = 1000
 n2 = 1
 runs_1000 = []
 runs_1 = []
 for i in range(9):
 t1 = elapsed('pbkdf2("password", "salt", iterations=%d)' % n1)
 t2 = elapsed('pbkdf2("password", "salt", iterations=%d)' % n2)
 runs_1000.append(t1)
 runs_1.append(t2)
 runs_1000.sort(); runs_1.sort()
 t1 = runs_1000[4]
 t2 = runs_1[4]
 measured_scale_exponent = math.log(t2 / t1, n2 / n1)
 self.assertLess(measured_scale_exponent, 1.1)
 }}}

 I haven't actually tested the above.

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