Re: [Django] #10498: Passing ugettext_lazy to related object's create() doesn't work

[Django]

#10498: Passing ugettext_lazy to related object's create() doesn't work
-+-
 Reporter:  mtredinnick  |Owner:  ojii
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:  dceu2011 |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Sorry about my benchmarks in comment:7, I was probably not targeting
 enough the object creation part in the executed tests. I can confirm
 Anssi's benchmarks, even if for query_all tests, I only get about 7%
 slower results.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17859: Undefined variable from import: cursor

[Django]

#17859: Undefined variable from import: cursor
-+-
 Reporter:  775725322@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Undefined variable   | Triage Stage:
  from import cursor |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

 Closing as ''needsinfo'' since I cannot reproduce with available details.

 Please provide a description of the environment that triggered the issue
 and a full traceback.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17857: CachedFilesMixin url_converter creates unnecessarily absolute urls

[Django]

#17857: CachedFilesMixin url_converter creates unnecessarily absolute urls
-+-
 Reporter:  tgecho   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 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 kmike):

 * cc: kmike84@… (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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17859: Undefined variable from import: cursor

[Django]

#17859: Undefined variable from import: cursor
-+-
 Reporter:   |  Owner:  nobody
  775725322@…| Status:  new
 Type:   |Version:  1.3
  Uncategorized  |   Keywords:  Undefined variable from import
Component:   |  cursor
  Uncategorized  |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 1def graph_templates(host_id):
 2from django.db import connection
 3cursor=connection.cursor()

 It marked an error at line 3 :Undefined variable from import: cursor

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by russellm):

 @shelldweller:

 When we make changes to a localflavor reflecting changes in
 provinces/codes etc, we generally list them in the release notes. For
 example, in 1.3, we corrected the code for the Yukon territory, and
 [https://docs.djangoproject.com/en/1.3/releases/1.3/#localflavor-changes
 documented it in the release notes]. In this case, it's not a backwards
 incompatible change, but the release notes are still the right place for a
 note.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10498: Passing ugettext_lazy to related object's create() doesn't work

[Django]

#10498: Passing ugettext_lazy to related object's create() doesn't work
-+-
 Reporter:  mtredinnick  |Owner:  ojii
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:  dceu2011 |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * stage:  Ready for checkin => Design decision needed


Comment:

 The attached patch does the Promise -> unicode conversion much later in
 the saving cycle. It fixes numerous other ways to pass Promise objects to
 the DB layer, and in addition the slowdown to model init is now removed.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17858: ugettext_lazy problem in models and modelsforms

[Django]

#17858: ugettext_lazy problem in models and modelsforms
--+--
 Reporter:  javier@…  |  Owner:  Javier
 Type:  Bug   | Status:  new
Component:  Translations  |Version:  1.3
 Severity:  Normal|   Keywords:  ugettext modelform forms
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 FIrst, sorry for my english, I'm Chilean.

 I'm trying to use i18n but this don't works fine.

 I made a model class
 {{{
 class Person(models.Model)
   name = models.CharField(_("name"), max_length=255)

 }}}

 and I use a modelForm

 {{{
 class PersonForm(ModelForm):
   class Meta:
 model = Person
 }}}

 when I show the PersonForm in a view this don't show anything, but if I
 use a {% trans "name" %} in a tempalte, this works fine.


 In some part I saw "Lazy unexpected type" in __wrapper__ I don't remember
 well.

 This is curios, when I put #,fuzzy in a .po file, the form show the
 translate god but not the template.




 I hope you can help me.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10491: Passing a unicode-proxy to HttpResponse classes doesn't work (was: an unevaluated lazy object)

[Django]

#10491: Passing a unicode-proxy to HttpResponse classes doesn't work
---+
 Reporter:  liangent   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10498: Passing ugettext_lazy to related object's create() doesn't work

[Django]

#10498: Passing ugettext_lazy to related object's create() doesn't work
-+-
 Reporter:  mtredinnick  |Owner:  ojii
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:  dceu2011 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * status:  closed => reopened
 * resolution:  fixed =>
 * severity:  Normal => Release blocker


Comment:

 While working on #17030 I noticed the isinstance(val, Proxy) calls in the
 model.`__init__`. I did some benchmarking, and confirmed the patch applied
 in this ticket causes some performance regressions. Using djangobench:
 {{{
 Running 'query_all' benchmark ...
 Min: 0.021516 -> 0.024808: 1.1530x slower
 Avg: 0.026032 -> 0.030944: 1.1887x slower
 Significant (t=-5.668286)
 Stddev: 0.00516 -> 0.00696: 1.3479x larger (N = 100)

 Running 'query_all_multifield' benchmark ...
 Min: 0.043492 -> 0.053683: 1.2343x slower
 Avg: 0.049113 -> 0.061782: 1.2580x slower
 Significant (t=-11.048640)
 Stddev: 0.00686 -> 0.00919: 1.3382x larger (N = 100)
 }}}

 When repeating the query_all_multifield the result seems to stay around
 20% slower (mentioning this because for some reason or other djangobench
 hasn't been that reliable).

 I am going to reopen and mark this ticket as a release blocker. The reason
 is that I think this should be reconsidered in the light of the 20%
 regression for fetching objects from the db. It seems pretty clear that
 the performance regression wasn't taken in account when doing the commit,
 so reconsidering this in light of the regression should be done before
 1.4. I am not saying that this must be reverted, just that reconsidering
 the value of the patch with the new info available should be done.

 My initial feeling is that the patch should be reverted, as using
 ugettext_lazy in models doesn't sound more important than the 20%
 regression. There are also a couple of other ways forward:
   - revert just the part of the commit which touches the args based
 setattr "fast path" loop. This leaves a bit of inconsistency, but args
 based `__init__` + ugettext_lazy isn't that common really.
   - check isinstance(Promise) when saving the model. That way .create()
 would work with ugettext lazy objects. I think there is still an unfixed
 problem if you just assign a Promise object to some field, then save (no,
 I haven't tested this).

 Attached is the full benchmark log.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17857: CachedFilesMixin url_converter creates unnecessarily absolute urls

[Django]

#17857: CachedFilesMixin url_converter creates unnecessarily absolute urls
-+-
 Reporter:  tgecho   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  SVN
 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 tgecho):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17857: CachedFilesMixin url_converter creates unnecessarily absolute urls

[Django]

#17857: CachedFilesMixin url_converter creates unnecessarily absolute urls
-+
 Reporter:  tgecho   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  SVN
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The url converter outputs absolute urls, even if they were originally
 defined as relative. If I do a collectstatic while DEBUG=True, it uses my
 local dev STATIC_URL.

 So url("../img/shadow.png") becomes
 url("/static/img/shadow.96b0bd7b6268.png")

 Only my production STATIC_URL is 'http://mystatic.s3.amazonaws.com/' so
 this link is broken when DEBUG=False

 That's just a symptom of the problem that the url converter bakes in
 whatever STATIC_URL is in effect when collectstatic is run. If the final
 result was a relative path, then it would work wherever the static files
 ended up living. So ideally url("../img/shadow.png") becomes
 url(".../img/shadow.96b0bd7b6268.png"). This file would be portable no
 matter what the STATIC_URL is set to.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17856: Pass "obj" parameter to get_inline_instances

[Django]

#17856: Pass "obj" parameter to get_inline_instances
---+--
 Reporter:  ybon   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kmike):

 * needs_tests:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17856: Pass "obj" parameter to get_inline_instances

[Django]

#17856: Pass "obj" parameter to get_inline_instances
---+--
 Reporter:  ybon   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kmike):

 * cc: kmike84@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17856: Pass "obj" parameter to get_inline_instances

[Django]

#17856: Pass "obj" parameter to get_inline_instances
---+
 Reporter:  ybon   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.4-beta-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 In the 1.4 rc1 release, a get_inline_instances method has been added in
 [source:/django/trunk/django/contrib/admin/options.py#L348 contrib.admin].

 This method does not accept the "obj" parameter.

 This is not consistent with the other methods of `ModelAdmin`:
 - get_formset
 - get_form
 - get_fieldsets
 - get_prepopulated_fields
 - get_readonly_fields

 My opinion is that the faster we make this change, the less painful it
 will be in the future.

 A patch is provided.

 (Discussion in [http://groups.google.com/group/django-
 developers/browse_thread/thread/19e8704d905297e7 this thread].)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17798: minor changes in localflavor.ca.ca_provinces

[Django]

#17798: minor changes in localflavor.ca.ca_provinces
--+
 Reporter:  shelldweller  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.localflavor   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by shelldweller):

 I'm not sure about documentation. PROVINCES_NORMALIZED is just an
 implementation detail which isn't documented anywhere presently and adding
 an extra key to it isn't worth mentioning anyway. RuntimeWarning was to
 warn users upgrading to 1.3 that there were recent changes in province
 codes. In 1.4 those changes aren't recent anymore.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10436: Application names i18n in the admin app broken

[Django]

#10436: Application names i18n in the admin app broken
-+-
 Reporter:  ramiro   |Owner:  ramiro
 Type:  Bug  |   Status:  reopened
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  blocktrans trans | Triage Stage:  Accepted
  app_label breadcrumbs capfirst |  Needs documentation:  0
  title  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 see #15810, similiar aproach using .title which can be translated

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16605: Can't client.login() in tests if contrib.SessionMiddleware is not in MIDDLEWARE_CLASSES

[Django]

#16605: Can't client.login() in tests if contrib.SessionMiddleware is not in
MIDDLEWARE_CLASSES
---+
 Reporter:  jbalogh|Owner:  ramiro
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by ramiro):

 * owner:  nobody => ramiro
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17854: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend

[Django]

#17854: Problem with DecimalField and big vlues of max_digits, decimal_places,
sqlite3 backend
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  DecimalField bug |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

 * severity:  Release blocker => Normal


-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17030: Remove special handling of deferred models in queryset iterators

[Django]

#17030: Remove special handling of deferred models in queryset iterators
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 The idea of this ticket isn't backwards compatible. Assume you have a
 model with fields a and b. Now, if you do qs.only('b'), the `__init__`
 will be called with args=[val_for_b]. If somebody has overriden the
 model's `__init__` this will break the contract of the `__init__` args. If
 args are given, the first one must be the value for first field, but after
 this patch it will be value for the second field. Hence this is backwards
 incompatible.

 So this would break:
 {{{
 class SomeModel:
a = TextField()
b = TextField()

def __init__(self, *args, **kwargs):
a_val = args[0] if args else kwargs.get('a')
if a_val == 'some value':
do_something()
super(SomeModel, self).__init__(*args, **kwargs)
 }}}
 Using the attached patch .only('b') will give b's value as first arg.
 Current code will init the model with kwargs['b'] = b's value.

 Wontfixing this is a bit sad, as the speedup of 1.5-2x for .defer/.only
 queries and over 2x for .raw queries can be important. These methods are
 often used for performance reasons.

 There is one trick that could be used: detect if the model has overridden
 `__init__` method (`Model.__init__ <> deferred_class.__init__`). If there
 is no overridden `__init__`, then it is safe to use the fast-path. However
 that feels a little dirty, so maybe this one should be given a wontfix:
 backwards incompatible resolution.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17854: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend (was: DecimalField problem (please see a possible solution in comments))

[Django]

#17854: Problem with DecimalField and big vlues of max_digits, decimal_places,
sqlite3 backend
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:
 Keywords:  DecimalField bug |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17854: DecimalField problem (please see a possible solution in comments) (was: DecimalField problem)

[Django]

#17854: DecimalField problem (please see a possible solution in comments)
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:
 Keywords:  DecimalField bug |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17854: DecimalField problem

[Django]

#17854: DecimalField problem
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:
 Keywords:  DecimalField bug |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 Replying to [comment:2 anonymous]:
 > Replying to [comment:1 anonymous]:
 > > The database is sqlite3
 > >
 > > The database field (for sqlite3) is 'decimal' (when the field type in
 the database is changed to say varchar(n) where n > (values to be stored
 (in this case probably 202)) - everything works perfectly.
 > >
 > > The problem seems to be that django emits the column type as decimal
 for sqlite3 (for other databases this problem is untested) instead of
 varchar(max_length + probably 2)
 >
 > typo resolution for the above line == instead of varchar(max_digits +
 probably 2)

 if does not create any side effect(s) a change to this might be the
 solution === django/db/backends/sqlite3/creation.py

 also similar change to respective backends might be the solution (in case
 a database has limits (unlike python Decimals) on the scale, precision for
 its corresponding column type)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17854: DecimalField problem

[Django]

#17854: DecimalField problem
--+--
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Uncategorized |  Version:  1.3
 Severity:  Release blocker   |   Resolution:
 Keywords:  DecimalField bug  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by anonymous):

 Replying to [comment:1 anonymous]:
 > The database is sqlite3
 >
 > The database field (for sqlite3) is 'decimal' (when the field type in
 the database is changed to say varchar(n) where n > (values to be stored
 (in this case probably 202)) - everything works perfectly.
 >
 > The problem seems to be that django emits the column type as decimal for
 sqlite3 (for other databases this problem is untested) instead of
 varchar(max_length + probably 2)

 typo resolution for the above line == instead of varchar(max_digits +
 probably 2)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17854: DecimalField problem

[Django]

#17854: DecimalField problem
--+--
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Uncategorized |  Version:  1.3
 Severity:  Release blocker   |   Resolution:
 Keywords:  DecimalField bug  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by anonymous):

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


Comment:

 The database is sqlite3

 The database field (for sqlite3) is 'decimal' (when the field type in the
 database is changed to say varchar(n) where n > (values to be stored (in
 this case probably 202)) - everything works perfectly.

 The problem seems to be that django emits the column type as decimal for
 sqlite3 (for other databases this problem is untested) instead of
 varchar(max_length + probably 2)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17855: DecimalField problem

[Django]

#17855: DecimalField problem
--+--
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Uncategorized |  Version:  1.4-beta-1
 Severity:  Release blocker   |   Resolution:  duplicate
 Keywords:  DecimalField bug  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by ramiro):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17792: pickled object's __setstate__() ignores exceptions

[Django]

#17792: pickled object's __setstate__() ignores exceptions
+
 Reporter:  rpq__@… |Owner:  nobody
 Type:  Uncategorized   |   Status:  reopened
Component:  Uncategorized   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  session pickle  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by ramiro):

 * stage:  Unreviewed => Accepted


Comment:

 Now we are talking. Tickets opened with a description of 109 characters
 (less than a Tweet) aren't useful at all for anyone.

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17855: DecimalField problem

[Django]

#17855: DecimalField problem
-+--
 Reporter:  anonymous|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Uncategorized|Version:  1.4-beta-1
 Severity:  Release blocker  |   Keywords:  DecimalField bug
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+--
 For a model field created as :: models.DecimalField(max_digits = 200,
 decimal_places = 100, blank = False, null = False)
 While using admin interface to insert a record involving such a
 DecimalField, the format changes (loss of precision and it uses scientific
 notation (even in the database)) (Please note - it works properly for low
 precision values (example - .987654321001234) - but for larger precision
 values (probably 15 decimal_places or more) it results in loss of
 precision)

 django version 1.3.1 and 1.4c1 (don't know about older versions);
 python 2.6.6;
 linux;

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17854: DecimalField problem

[Django]

#17854: DecimalField problem
-+--
 Reporter:  anonymous|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Uncategorized|Version:  1.3
 Severity:  Release blocker  |   Keywords:  DecimalField bug
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+--
 For a model field created as :: models.DecimalField(max_digits = 200,
 decimal_places = 100, blank = False, null = False)
 While using admin interface to insert a record involving such a
 DecimalField, the format changes (loss of precision and it uses scientific
 notation (even in the database)) (Please note - it works properly for low
 precision values (example - .987654321001234) - but for larger precision
 values (probably 15 decimal_places or more) it results in loss of
 precision)

 django version 1.3.1 and 1.4c1 (don't know about older versions);
 python 2.6.6;
 linux;

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17853: Fixture error output has wrong fixture name

[Django]

#17853: Fixture error output has wrong fixture name
-+-
 Reporter:  treborhudson@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:
  commands)  |  1.4-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17327: contrib.auth management commands ignores --database option

[Django]

#17327: contrib.auth management commands ignores --database option
-+-
 Reporter:  skam |Owner:
|  brianriley
 Type:  New feature  |   Status:  reopened
Component:  contrib.auth |  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:  django db models | Triage Stage:  Ready for
  createsuperuser management |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * severity:  Normal => Release blocker


-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #361: Some Basic Math Filters

[Django]

#361: Some Basic Math Filters
-+--
 Reporter:  ilikeprivacy@…   |Owner:  adrian
 Type:  defect   |   Status:  closed
Component:  Template system  |  Version:
 Severity:  normal   |   Resolution:  wontfix
 Keywords:  filter math  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Robert Wallner):

 I think this is a common misconception. Business logic code doesn't belong
 in the template, but at the same time, template logic doesn't belong in
 the code. So, not having arithmetic operations in the template do exactly
 the opposite. It encourages users to put the template logic inside their
 code, which is as bad as placing business logic code inside templates.
 Reminds me of Ocam's razor :)

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17851: Db Field instances cannot be compared to other objects

[Django]

#17851: Db Field instances cannot be compared to other objects
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  field compare|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.