Re: [Django] #19210: django.utils.timesince() does not account for leap years

[Django]

#19210: django.utils.timesince() does not account for leap years
--+
 Reporter:  jnns  |Owner:  hirokiky
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  date time | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by hirokiky):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #19160: Make ungettext_lazy really usable

[Django]

#19160: Make ungettext_lazy really usable
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  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
--+

Comment (by anonymous):

 I asked Jacob on IRC: he thinks it's possible to switch to single-
 underscore-prefixes in `lazy`.

-- 
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] #19160: Make ungettext_lazy really usable

[Django]

#19160: Make ungettext_lazy really usable
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  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
--+

Comment (by aaugustin):

 I reviewed the patch.

 

 To sum up, the concept of `*_lazy` functions is to return a proxy object
 that stores the original function and its argument. When the proxy object
 is converted to a string, the function is evaluated. It can return
 different results if it takes into account a global (usually thread-local)
 variable — hire, the active language.

 The complication here is that the `number` argument isn't known when the
 proxy object is built. We don't want to add an API to insert it (as
 acknowledged in comment 7). We want to extract it automatically when
 string interpolation is used on the proxy object (ie. the `%` operator,
 that invokes `__mod__`).

 It would still be easy to inject the extra keyword argument, if keyword
 arguments weren't a "private" attribute of the proxy class
 (`__proxy__.__kw`)! "Private" attributes aren't actually private in
 Python; we can still set them with the `__` hack.
 Ugly — that's what we get for bending `django.utils.functional.lazy`.

 (By the way, injecting a keyword argument is better than injecting a
 positional argument, because it works regardless of whether the previous
 arguments were positional or keyword arguments.)

 The current implementation of `lazy` dates back to
 
[https://github.com/django/django/commit/5cf8f684237ab5addaf3549b2347c3adf107c0a7#L53R6
 the merge of the i18n branch], more than 7 years ago. Maybe we could
 switch from double-underscore-prefixes to single-underscore-prefixes,
 alleviating the need for the `__` hack?

 That won't change fundamentally the implementation — we're still hacking
 the proxy object's internals — but at least that'll avoid using a not-so-
 well-known Python hack.

 

 There's a little bit of work on the patch, but it can be done by the
 committer:

 - In the docs: `.. versionadded:: 1.5` => `.. versionchanged:: 1.6`.
 - The docs could use a little bit of copy-editing.
 - In the tests: `s = ungettext_lazy("%d good result", "%d good result")`
 => the second arg should be a plural.

 

 Last minute thought: if the ngettext function gets called with
 `number=None` — for instance because the lazy object is resolved without
 interpolation — is it easy to understand the traceback? We're explicitly
 introducing a default value of `number=None` here, possibly triggering
 complicated errors when the developer doesn't use one of the three
 supported syntaxes.

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

[Django]

#3148: Add getters and setters to model fields
-+-
 Reporter:  jerf@…   |Owner:
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 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 anonymous):

 Anyone looking for a simple answer to this problem without using an
 underscore in the database could try:

 http://www.korokithakis.net/posts/how-replace-django-model-field-property/


 {{{
 classMyClass(models.Model):
 _my_date=models.DateField(db_column="my_date")

 @property
 def my_date(self):
 return self._my_date

 @my_date.setter
 def my_date(self,value):
 if value>datetime.date.today():
 logger.warning("The date chosen was in the future.")
 self._my_date=value
 }}}

 Augustin's solution was half complete.

-- 
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] b64135: [1.5.x] Replaced deprecated sslerror by ssl.SSLErr...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: b641357a37528c39de0c181ad495cbd39f3bf530
  
https://github.com/django/django/commit/b641357a37528c39de0c181ad495cbd39f3bf530
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/core/mail/backends/smtp.py

  Log Message:
  ---
  [1.5.x] Replaced deprecated sslerror by ssl.SSLError

The exact conditions on which this exception is raised are not
known, but this replacement is the best guess we can do at this
point.
Backport of 850630b4b7 from master.



-- 
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] 850630: Replaced deprecated sslerror by ssl.SSLError

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 850630b4b7e79b76ad9732db1be6a2aa4257893f
  
https://github.com/django/django/commit/850630b4b7e79b76ad9732db1be6a2aa4257893f
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/core/mail/backends/smtp.py

  Log Message:
  ---
  Replaced deprecated sslerror by ssl.SSLError

The exact conditions on which this exception is raised are not
known, but this replacement is the best guess we can do at this
point.



-- 
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] 624883: Added documentation for the 'db' argument of the p...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6248833d9e35926d6ccd4b4d602f7ea89fea0c74
  
https://github.com/django/django/commit/6248833d9e35926d6ccd4b4d602f7ea89fea0c74
  Author: mpaolini 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/db/models/signals.py
M docs/ref/signals.txt

  Log Message:
  ---
  Added documentation for the 'db' argument of the post-syncdb signal.



-- 
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] #19562: Documentation: How Django stores passwords out of date

[Django]

#19562: Documentation: How Django stores passwords out of date
--+-
 Reporter:  startup.canada@…  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.auth  |Version:  1.5-alpha-1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 In "Password management in Django" documentation page
 https://docs.djangoproject.com/en/1.5/topics/auth/passwords/ , section
 "How Django stores passwords" it says: "The password attribute of a User
 object is a string in this format:
 algorithm$hash"

 This is out of date (since v1.4?) It should say something like:

 "The password attribute of a User object is a string in this format:
 algorithm$iterations$salt$hash" , where iterations is the work factor.

 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] #19561: Through-table model attributes are not available

[Django]

#19561: Through-table model attributes are not available
-+--
 Reporter:  qcwxezdas@…  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  ORM aggregation  |Version:  1.5-beta-1
 Severity:  Normal   |   Keywords:  orm,many-to-many,through
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+--
 Here's my code:


 {{{
 class Property(models.Model):
 title = models.CharField(_("Title"), max_length=150, unique=True)
 default_description = models.TextField(_("Default description"),
 blank=True)

 class AccommodationProperty(models.Model):
 accommodation = models.ForeignKey("Accommodation")
 prop = models.ForeignKey(Property, verbose_name=_("Property"),
  db_column="property")

 custom_description = models.TextField(_("Custom description"),
 blank=True)

 class Service(models.Model):
 title = models.CharField(_("Title"), max_length=150)

 class Accommodation(Service):
 properties = models.ManyToManyField(Property,
 through=AccommodationProperty,
 related_name="accommodations",
 blank=True)
 }}}

 And here's what's wrong:


 {{{
 >>> acprop = AccommodationProperty.objects.all()[0]
 >>> acprop.accommodation
 
 >>> acprop.prop
 
 >>> acprop.custom_description
 u'customas'
 >>> acprop.prop.default_description
 u'defaultas'
 >>> ac = acprop.accommodation
 >>> ac.properties.all()
 []
 >>> prop = ac.properties.all()[0]
 >>> prop.default_description
 u'defaultas'
 >>> prop.title
 u'Internetas'
 >>> prop.custom_description
 Traceback (most recent call last):
   File "", line 1, in 
 AttributeError: 'Property' object has no attribute 'custom_description'
 >>>
 }}}

 Attribute custom_description cannot be accessed.

-- 
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] #19382: Closing SMTP backend raises AttributeError when already closed

[Django]

#19382: Closing SMTP backend raises AttributeError when already closed
-+
 Reporter:  sebastian_noack  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"5b8c0d22cc07ca727c032edf3309fab9cb39f21d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5b8c0d22cc07ca727c032edf3309fab9cb39f21d"
 [1.5.x] Fixed #19382 -- Stopped smtp backend raising exception when
 already closed

 Thanks Sebastian Noack for the report and the initial patch.
 Backport of ffa50ca35 from master.
 }}}

-- 
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] #19134: Can't close SMTP connection, when already disconnected.

[Django]

#19134: Can't close SMTP connection, when already disconnected.
--+
 Reporter:  sebastian_noack   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Mail)   |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"4081042ef51c0e679c78f2d0d13514af3434ed13"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4081042ef51c0e679c78f2d0d13514af3434ed13"
 [1.5.x] Fixed #19134 -- Allowed closing smtp backend when the server is
 stopped

 Thanks Sebastian Noack for the report and the initial patch.
 Backport of 1b3f832ab7 from master.
 }}}

-- 
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] 408104: [1.5.x] Fixed #19134 -- Allowed closing smtp backe...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 4081042ef51c0e679c78f2d0d13514af3434ed13
  
https://github.com/django/django/commit/4081042ef51c0e679c78f2d0d13514af3434ed13
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/core/mail/backends/smtp.py
M tests/regressiontests/mail/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19134 -- Allowed closing smtp backend when the server is 
stopped

Thanks Sebastian Noack for the report and the initial patch.
Backport of 1b3f832ab7 from master.


  Commit: 5b8c0d22cc07ca727c032edf3309fab9cb39f21d
  
https://github.com/django/django/commit/5b8c0d22cc07ca727c032edf3309fab9cb39f21d
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/core/mail/backends/smtp.py
M tests/regressiontests/mail/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19382 -- Stopped smtp backend raising exception when already 
closed

Thanks Sebastian Noack for the report and the initial patch.
Backport of ffa50ca35 from master.


Compare: https://github.com/django/django/compare/a893ee3315d6...5b8c0d22cc07

-- 
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] 1b3f83: Fixed #19134 -- Allowed closing smtp backend when ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1b3f832ab7291b6d92a27288bb97b3a3b712ebcb
  
https://github.com/django/django/commit/1b3f832ab7291b6d92a27288bb97b3a3b712ebcb
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/core/mail/backends/smtp.py
M tests/regressiontests/mail/tests.py

  Log Message:
  ---
  Fixed #19134 -- Allowed closing smtp backend when the server is stopped

Thanks Sebastian Noack for the report and the initial patch.


  Commit: ffa50ca35219aa328e8e4ecda450a53c27c2e710
  
https://github.com/django/django/commit/ffa50ca35219aa328e8e4ecda450a53c27c2e710
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/core/mail/backends/smtp.py
M tests/regressiontests/mail/tests.py

  Log Message:
  ---
  Fixed #19382 -- Stopped smtp backend raising exception when already closed

Thanks Sebastian Noack for the report and the initial patch.


Compare: https://github.com/django/django/compare/84ea85fb90a3...ffa50ca35219

-- 
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] #19559: Writing your first Django app, part 2 error

[Django]

#19559: Writing your first Django app, part 2 error
---+--
 Reporter:  ranamalo   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 The tutorial definitely works with this line — I've gone through it
 entirely more than once just before the 1.4 release.

 There isn't anything we can do for you with so little information. My
 advice from #19558 applies here too.

-- 
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] #19558: Writing your first Django app, part 1 error

[Django]

#19558: Writing your first Django app, part 1 error
---+--
 Reporter:  ranamalo   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 Configuring the locale in application code isn't necessary in general. The
 tutorial works for me without this, and I've run Django in a variety of
 environment without needing it.

 Since you didn't provide any information on what happened before you added
 this to your settings, I cannot analyze anything, let alone identify a bug
 in Django.

 All I can say is that locale belongs in system configuration rather than
 in application code.

 I suggest using Django's [TicketClosingReasons/UseSupportChannels support
 channels], and if necessary, to reopen this ticket with more information —
 at least the full traceback and the output of `locale`.

-- 
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] #19560: Please improve warning message "received a naive datetime while time zone support is active"

[Django]

#19560: Please improve warning message "received a naive datetime while time 
zone
support is active"
-+-
 Reporter:  gcc  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 The documentation explains how to turn the warnings into exceptions,
 providing a full backtrace.

-- 
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] #19560: Please improve warning message "received a naive datetime while time zone support is active"

[Django]

#19560: Please improve warning message "received a naive datetime while time 
zone
support is active"
--+
 Reporter:  gcc   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The warning message usually shows:

 {{{
 BadDataError: ('payment.Order', RuntimeWarning(u'DateTimeField received a
 naive datetime (2013-01-03 19:45:41.532391) while time zone support is
 active.',))
 }}}

 However it doesn't actually show which field this happened to, which makes
 it hard to debug without inserting breakpoints.

 This three-line change to `django.db.models.fields.DateTimeField`:

 {{{
 def get_prep_value(self, value):
 value = self.to_python(value)
 if value is not None and settings.USE_TZ and
 timezone.is_naive(value):
 ...
 -warnings.warn("DateTimeField received a naive datetime (%s)"
 -  " while time zone support is active." % value,
 +warnings.warn("DateTimeField %s.%s received a naive datetime
 (%s)"
 +  " while time zone support is active." %
 +  (self.model.__name__, self.name, value),
   RuntimeWarning)
 }}}

 Which results in this output instead:

 {{{
 DateTimeField Order.created received a naive datetime (2013-01-03
 20:11:24.084774) while time zone support is active.
 }}}

-- 
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] #19559: Writing your first Django app, part 2 error

[Django]

#19559: Writing your first Django app, part 2 error
---+
 Reporter:  ranamalo   |  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
---+
 I had to comment out this line in settings.py in order to be able to
 access the admin site:

 {{{
 'django.contrib.sites',
 }}}

-- 
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] #19558: Writing your first Django app, part 1 error

[Django]

#19558: Writing your first Django app, part 1 error
---+
 Reporter:  ranamalo   |  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
---+
 I had to add the following to my settings.py in order to run syncdb:

 {{{
 import os
 os.environ['LANG'] = 'en_US.UTF-8'
 }}}

-- 
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] #19426: EmptyQuerySet.distinct does not have the same signature as QuerySet.distinct()

[Django]

#19426: EmptyQuerySet.distinct does not have the same signature as
QuerySet.distinct()
-+-
 Reporter:  anonymous|Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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:  1|UI/UX:  0
-+-

Comment (by claudep):

 I committed the fix without the test, as #19184 will probably remove this
 part anyway.

-- 
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] #19426: EmptyQuerySet.distinct does not have the same signature as QuerySet.distinct()

[Django]

#19426: EmptyQuerySet.distinct does not have the same signature as
QuerySet.distinct()
-+-
 Reporter:  anonymous|Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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:  1|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"a893ee3315d6a134b46ff8c36c44a8efbbe34886"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a893ee3315d6a134b46ff8c36c44a8efbbe34886"
 Fixed #19426 -- Adapted EmptyQuerySet.distinct signature

 1.5-only change, as EmptyQuerySet will be refactored in 1.6.
 Thanks hongshun...@gmail.com 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] a893ee: Fixed #19426 -- Adapted EmptyQuerySet.distinct sig...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: a893ee3315d6a134b46ff8c36c44a8efbbe34886
  
https://github.com/django/django/commit/a893ee3315d6a134b46ff8c36c44a8efbbe34886
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

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

  Log Message:
  ---
  Fixed #19426 -- Adapted EmptyQuerySet.distinct signature

1.5-only change, as EmptyQuerySet will be refactored in 1.6.
Thanks hongshun...@gmail.com 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] #19546: Add logging configuration to test_sqlite.py

[Django]

#19546: Add logging configuration to test_sqlite.py
--+
 Reporter:  bak1an|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ptone):

 Replying to [comment:9 aaugustin]:
 > Would it be easier to capture stderr entirely?

 I had tried that with a local instance of DjangoTestSuiteRunner - but
 invoking it's run_tests method inside a test proved too thorny and I went
 the admin scripts route.

 unittest does something funky to capture/store the original stderr stream
 at least for warnings before running the test, even before the setUp
 method - I find this surprising, but can't explain why this strategy
 doesn't work

 so the straightforward way to attempt this isn't working, this gist
 represents my increasingly verbose attempt - which does not work:

 https://gist.github.com/864

 I know some would say 1-2 seconds isn't that long - but I still find that
 a sort of painful addition.

-- 
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] #16614: Support server-side cursors for queryset iteration in database backends

[Django]

#16614: Support server-side cursors for queryset iteration in database backends
-+-
 Reporter:  toofishes|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  memory cursors   |  Needs documentation:  1
  database   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by trbs):

 * cc: trbs@… (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/django] 84ea85: Updated comment about PostGIS bug 2035

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 84ea85fb90a3914fef9ab74b1f4f5bb919bec068
  
https://github.com/django/django/commit/84ea85fb90a3914fef9ab74b1f4f5bb919bec068
  Author: Claude Paroz 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/contrib/gis/tests/geoapp/tests.py

  Log Message:
  ---
  Updated comment about PostGIS bug 2035

PostGIS 2.0.2 has been released on December 3rd 2012, with the
fix included.



-- 
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] 70cc95: [1.5.x] Fixed #19545 -- Make sure media/is_multipa...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 70cc95d1ccab823d30d123d17e864c4867ee244b
  
https://github.com/django/django/commit/70cc95d1ccab823d30d123d17e864c4867ee244b
  Author: Simon Charette 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/forms/formsets.py
M tests/regressiontests/forms/tests/formsets.py

  Log Message:
  ---
  [1.5.x] Fixed #19545 -- Make sure media/is_multipart work with empty formsets

Backport of 3fc43c964e from master.



-- 
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] #19545: `BaseFormSet`'s `media` and `is_multipart` don't work correctly when `extra=0`

[Django]

#19545: `BaseFormSet`'s `media` and `is_multipart` don't work correctly when
`extra=0`
---+
 Reporter:  charettes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Claude Paroz ):

 In [changeset:"70cc95d1ccab823d30d123d17e864c4867ee244b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="70cc95d1ccab823d30d123d17e864c4867ee244b"
 [1.5.x] Fixed #19545 -- Make sure media/is_multipart work with empty
 formsets

 Backport of 3fc43c964e from master.
 }}}

-- 
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] #19545: `BaseFormSet`'s `media` and `is_multipart` don't work correctly when `extra=0`

[Django]

#19545: `BaseFormSet`'s `media` and `is_multipart` don't work correctly when
`extra=0`
---+
 Reporter:  charettes  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"3fc43c964ef7ab52261ec3a164d66b19f06f5cea"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3fc43c964ef7ab52261ec3a164d66b19f06f5cea"
 Fixed #19545 -- Make sure media/is_multipart work with empty formsets
 }}}

-- 
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] 3fc43c: Fixed #19545 -- Make sure media/is_multipart work ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3fc43c964ef7ab52261ec3a164d66b19f06f5cea
  
https://github.com/django/django/commit/3fc43c964ef7ab52261ec3a164d66b19f06f5cea
  Author: Simon Charette 
  Date:   2013-01-03 (Thu, 03 Jan 2013)

  Changed paths:
M django/forms/formsets.py
M tests/regressiontests/forms/tests/formsets.py

  Log Message:
  ---
  Fixed #19545 -- Make sure media/is_multipart work with empty formsets



-- 
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] #18129: Capitalization of verbose_name bad design decision. Why waste computer power.

[Django]

#18129: Capitalization of verbose_name bad design decision. Why waste computer
power.
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Uncategorized|   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  capitalize   |  Unreviewed
  verbose_name   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mail@…):

 I agree with the contributor: when verbose_name is explicitely set it
 should at least be possible to disable automatic capitalisation. I have an
 verbose_name label that reads something like this "xABC". The lowercased x
 in the Acronym is semantically relevant. Auto-capitalization destroys
 that. Hopefully there's an easy, and consistent way to override that
 behavior.

-- 
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] #16612: Localized form fields cause Form.has_changed() to always return True.

[Django]

#16612: Localized form fields cause Form.has_changed() to always return True.
---+
 Reporter:  rviotti@…  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3
 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
---+

Comment (by claudep):

 #19557 is a duplicate with a patch (for the specific OP 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] #19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets with is_localized=True

[Django]

#19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets
with is_localized=True
+--
 Reporter:  jrief   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.4
 Severity:  Normal  |   Resolution:  duplicate
 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 claudep):

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


Comment:

 Thanks, but this has already been reported in #16612.

-- 
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] #19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets with is_localized=True

[Django]

#19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets
with is_localized=True
+--
 Reporter:  jrief   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.4
 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 mjtamlyn):

 * 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jeremyt):

 [https://github.com/jtillman/django/compare/ticket_19385] rebased with
 recent updated. Good additions btw.

 Here are my thoughts/plans for the current list:
 * IN lookups:
  * Multicolumn could be done in mysql with multicolumn IN with format
 "SELECT * FROM T1 WHERE (T1.col1, T1.col2) IN ((11, 12), (21, 22))" but
 this isn't widely support by all databases so I'm staying away.
  * This could be done by converting the IN filter into a Q object which
 explains the IN using ANDs and ORs of single fields as done in
 prefetching. Either we could create a field lookup that return a list of
 constraints or create a method on the field that takes in the query and
 adds the constraints itself..(I favor the latter).
 * Subquery support
  * Could use multicolumn IN here too but no for same reason
  * I agree with the use of EXISTS over IN but I'm a little hesitant on
 this because mysql struggles with dependent subqueries (supposed to be
 fixed in 5.6). An option would be to special case single column relations
 and use IN and use exists for multicase scenario.
 * Join trimming
  * Shouldn't change much but we'll have to return a list of columns in
 trim_joins I'm thinking???
 * Representation of the foreign key in the models's _meta
  * I'm currently not sure why we need this one.

 Thoughts?

 All feedback/discussion welcome.

-- 
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] #19553: Please make save_instance and construct_instance methods of ModelForm

[Django]

#19553: Please make save_instance and construct_instance methods of ModelForm
-+-
 Reporter:  gcc  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Forms|   Resolution:  wontfix
 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 gcc):

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


Comment:

 Thanks charettes, that's an excellent idea.

 Now that you suggested it, I found the
 [[https://docs.djangoproject.com/en/dev/topics/class-based-views/generic-
 editing/#models-and-request-user|documentation]] that proposes almost
 exactly this use 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] #19554: ChangeList.url_for_result work only for "admin" Site

[Django]

#19554: ChangeList.url_for_result work only for "admin" Site
-+-
 Reporter:  tecnosegugio@…   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.admin|  Version:
 Severity:  Normal   |  1.5-beta-1
 Keywords:  Admin, AdminSite,|   Resolution:  invalid
  ChangeList | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by rafales):

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


Comment:

 `current_app` argument decides what instance of admin site is being used.
 `admin` in format string is application name, not an instance name.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets with is_localized=True

[Django]

#19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets
with is_localized=True
+--
 Reporter:  jrief   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.4
 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 anonymous):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Forms
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Bug


-- 
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] #19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets with is_localized=True

[Django]

#19557: forms.widgets.Widget._has_changed() erroneously returns True on Widgets
with is_localized=True
---+
 Reporter:  jrief  |  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
---+
 How to reproduce:
 In settings.py set {{{USE_L10N=True}}} and set your locale to a language
 which uses a comma as decimal separator.
 Create a form with fields for Float or Decimal and give them an initial
 value.
 On the corresponding widget, set {{{is_localized=True}}}.

 If this form is rendered, the initial values are displayed using a comma
 instead of a dot. If the client resubmits this form without changing any
 value, the method {{{forms.widgets.Widget._has_changed()}}} erroneously
 returns True, because it compares a decimal string using a comma as
 decimal separator (from the input field) with a string using a dot (from
 the initial value).

 The attached patch worked for 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 https://groups.google.com/groups/opt_out.

Re: [Django] #19555: tutorial pt 1 - update year for examples to work

[Django]

#19555: tutorial pt 1 - update year for examples to work
--+
 Reporter:  rodrigorosa.lg@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  year  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by aaugustin):

 I hadn't noticed that the tutorial created objects with the date set to
 "now", and then proceeded to filter on the year.

-- 
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] #19555: tutorial pt 1 - update year for examples to work

[Django]

#19555: tutorial pt 1 - update year for examples to work
--+
 Reporter:  rodrigorosa.lg@…  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  year  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * status:  closed => new
 * type:  Uncategorized => Cleanup/optimization
 * version:  1.4 => master
 * easy:  0 => 1
 * resolution:  wontfix =>
 * stage:  Unreviewed => Accepted


Comment:

 As discussed on IRC:
 {{{
 mYk: claudep: , yeah, we should use a different example then
 mYk: filter on a field other than the date
 }}}

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