Re: [Django] #8462: length and length_is filters don't fail silently

[Django]

#8462: length and length_is filters don't fail silently
--+-
  Reporter:  magneto  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:  length
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  1|  
--+-
Changes (by SmileyChris):

  * needs_better_patch:  => 1
  * stage:  Unreviewed => Accepted
  * summary:  template tag Length and the 'error' => length and length_is
  filters don't fail silently
  * needs_tests:  => 1
  * needs_docs:  => 0

Comment:

 This is also an issue for `length_is`.

 I think returning `''` would make more sense for the length filter (it's
 invalid, not `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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9212: German Umlauts and possible other foreign languages special characters

[Django]

#9212: German Umlauts and possible other foreign languages special characters
---+
  Reporter:  nekron| Owner:  nobody  
Status:  new   | Milestone:  post-1.0
 Component:  Internationalization  |   Version:  SVN 
Resolution:|  Keywords:  Umlauts 
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 Oh, I see what's happening. Yes, it's treating the input as iso-8859-1. So
 you're right: We have to decode from utf-8 back to unicode, then see what
 it would look like if treated as iso-8859-1 and then know that that is
 really the UTF-8 bytestrings. Good grief.

 It also just occurred to me how fragile this is. It means any Python input
 files using bytes that don't fit into ISO-8859-1 cannot be handled by that
 old xgettext version. That's just going to be tough luck for those people
 and they'll have to get a more recent gettext; the tool isn't flexible
 enough to handle varying encodings. But we will have to document that
 limitation (in the "coming one day soon now, hopefully" rewrite of
 i18n.txt to be something comprehensible).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9279: loaddata should have an option to ignore data for fields that no longer exist

[Django]

#9279: loaddata should have an option to ignore data for fields that no longer
exist
-+--
 Reporter:  [EMAIL PROTECTED]  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 For developers it would be a very nice if loaddata had an option
 --ignorenonexistent, that just ignores entries in the serialised data for
 fields that have been removed from the database. At the moment I see
 myself going through endless text files, deleting all the entries for
 these fields, just to port the data across.

 I'm not suggesting that this should ever be the default behaviour.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9245: django.db.models.fields.Field forces use of TypedChoiceField

[Django]

#9245: django.db.models.fields.Field forces use of TypedChoiceField
---+
  Reporter:  Tarken| Owner:  badri
Status:  assigned  | Milestone:   
 Component:  Forms |   Version:  1.0  
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by badri):

  * owner:  nobody => badri
  * 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9212: German Umlauts and possible other foreign languages special characters

[Django]

#9212: German Umlauts and possible other foreign languages special characters
---+
  Reporter:  nekron| Owner:  nobody  
Status:  new   | Milestone:  post-1.0
 Component:  Internationalization  |   Version:  SVN 
Resolution:|  Keywords:  Umlauts 
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 OK, I can take a look at fixing it by figuring out the xgettext version
 and undoing the mangling for xgettexts older than 0.15 (maybe I should
 verify that's specifically when it was fixed also).  Only I think the
 encoding names need to be reversed there -- what you show is essentially
 what xgettext is doing and we need to reverse that:

 {{{
 >>> u = u'\xdf'
 >>> print u
 ß
 >>> e1 = u.encode('utf-8')
 >>> e1
 '\xc3\x9f'
 >>> e2 = e1.decode('iso-8859-1').encode('utf-8')
 >>> e2
 '\xc3\x83\xc2\x9f'
 >>> e3 = e2.decode('utf-8').encode('iso-8859-1')
 >>> e3
 '\xc3\x9f'
 }}}

 e1 is the bytes in the source .py file, e2 is what the older xgettext
 outputs, e3 is what we want instead (same as e1).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6652: Allow 'clean()' to specify the wrong field

[Django]

#6652: Allow 'clean()' to specify the wrong field
--+-
  Reporter:  Daniele Varrazzo <[EMAIL PROTECTED]>  | Owner:  
nobody  
Status:  reopened | Milestone:  
post-1.0
 Component:  Forms|   Version:  SVN 

Resolution:   |  Keywords:  
feature 
 Stage:  Design decision needed   | Has_patch:  1   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by mtredinnick):

 I don't like the approach proposed here now that I've looked at it a bit
 more. `ValidationError` is an exception that should be raised and is then
 caught by the outer loop (in normal single-field processing) and stored in
 the `ErrorList`. A validation error is the exception instance, not tied to
 a field. The conceptual problem here is that `Form.clean()` is for
 validating multiple fields at once, so you don't want to raise an
 exception on the first problem: you still want to handle all errors and
 it's not part of some outer loop that gets called again and again.

 Documenting `_errors`, which is designed to hold the errors and can be
 happily used by subclasses is a better approach here. I'll do that today
 and then close this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8462: length and length_is filters don't fail silently

[Django]

#8462: length and length_is filters don't fail silently
--+-
  Reporter:  magneto  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:  length
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  1|  
--+-
Comment (by mtredinnick):

 I agree with Chris: if you're applying `length` or `length_is` to
 something that isn't measurable, it's an invalid usage, so returning an
 empty string is probably better.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9212: German Umlauts and possible other foreign languages special characters

[Django]

#9212: German Umlauts and possible other foreign languages special characters
---+
  Reporter:  nekron| Owner:  nobody  
Status:  new   | Milestone:  post-1.0
 Component:  Internationalization  |   Version:  SVN 
Resolution:|  Keywords:  Umlauts 
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

 * cc: mtredinnick (added)
  * stage:  Unreviewed => Accepted

Comment:

 Oh, I've played this game before. :-( gettext seemed to make a new release
 every couple of months in the early years of this decade and working out
 which version added new features was ''hard''.

 I'm inclined to be nice to older versions -- in the sense of working
 around their limitations -- because it isn't always easy to upgrade and I
 don't want to put a big learning curve in the form of compiling the
 toolchain in the way of people trying to localise their applications. If
 somebody can work out how to get the version number out of xgettext so
 that we can do it in the Python code, I'm very happy to put something into
 `makemessages.py` that looks like

 {{{
 #!python
 if version < (0, 15, 0):
output_text = output_text.decode('iso-8859-1').encode('utf-8')
 }}}

 I have a feeling that using a reg-exp on the first line of output from
 `xgettext --version` is going to be enough here. I seem to recollect (from
 working on GNOME's intltool) that that was enough to work out the version
 pretty reliably. We'll only need the major and minor number.

 We have a requirement that the source text '''must''' be in UTF-8 for
 strings being sent to gettext and so we don't support things like
 `codding: iso-8859-1`. Gettext and other tools aren't smart enough to
 understand that sort of stuff (they just do a lexical scan of the file,
 they don't understand too much about Python), so I'm comfortable with
 making that a requirement for people writing the source. But that means we
 have to actually support UTF-8. So if older gettext versions are treating
 things as iso-8859-1 by default, I can live with using programmatic
 hammers to force them back to UTF-8. No bytes get lost in the conversion
 process; it's just that the intermediate text doesn't make any sense (as
 noted in the original bug report).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8652: Multiline tags and tag escape tags

[Django]

#8652: Multiline tags and tag escape tags
-+--
  Reporter:  Michael Manfre <[EMAIL PROTECTED]>  | Owner:  
nobody  
Status:  closed  | Milestone:   
   
 Component:  Template system |   Version:  SVN  
   
Resolution:  wontfix |  Keywords:  
escape multiline
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 This looks a lot like two requests in one ticket and we all know how that
 isn't a good approach.

  1. Multiline template tags aren't going to happen. We've made a decision
 on that plenty of times.
  2. Adding a whole extra way to write template tags just to support this
 one particular use-case when you could just as easily write a shorter
 template tag for your own use is adding a bunch of maintenance overhead to
 Django for not a lot of gain. We have to keep the code correct, keep the
 documentation correct, explain it to people, incorporate the testing
 overhead, etc. Not worth it. If you have a need to do this a lot and don't
 want to write out "templatetag", write a shorter tag that calls
 templatetag internally. Or write a pre-processor for your templates. But
 this isn't worth adding code to Django for.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7806: django.template refactoring

[Django]

#7806: django.template refactoring
--+-
  Reporter:  emulbreh | Owner:  nobody  
Status:  new  | Milestone:  post-1.0
 Component:  Template system  |   Version:  SVN 
Resolution:   |  Keywords:  tplrf   
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  1|   Needs_tests:  1   
Needs_better_patch:  1|  
--+-
Comment (by SmileyChris):

 This is all incredibly impressive, emulbreh.

 I've got a tag token parser which has a different tact - you're more than
 welcome to a look. Send me an email if you're interested - [EMAIL PROTECTED]

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8966: {% if "x"|length_is:n %} always evaluates True

[Django]

#8966: {% if "x"|length_is:n %} always evaluates True
-+--
  Reporter:  Thomas Steinacher <[EMAIL PROTECTED]>  | Owner:  
carljm
Status:  new | Milestone:   
 
 Component:  Template system |   Version:  SVN  
 
Resolution:  |  Keywords:   
 
 Stage:  Ready for checkin   | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by carljm):

  * owner:  nobody => carljm

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9274: Support MySQLdb >= 1.3.0

[Django]

#9274: Support MySQLdb >= 1.3.0
+---
  Reporter:  Dave St.Germain <[EMAIL PROTECTED]>  | Owner:  
nobody 
Status:  new| 
Milestone: 
 Component:  Database layer (models, ORM)   |   
Version:  1.0
Resolution: |  
Keywords:  mysqldb
 Stage:  Someday/Maybe  | 
Has_patch:  1  
Needs_docs:  0  |   
Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Someday/Maybe
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 As far as I can tell from the sourceforge page, there is no release called
 1.3.0 yet. Our policy is not to worry about chasing unreleased versions,
 at least until the get to release-candidate mode, since plenty of things
 could change between now and release time (and have done in the past, both
 with MySQLdb and other modules we rely upon).

 For example, the fact that those particular functions have been moved
 inside an underscore-prefixed attribute means they probably aren't
 intended to be used by public code any longer. That may be a bug in
 MySQLdb, since presumably one is meant to be able to get the server
 version and check connection liveness or it may be that Andy is intended
 to provide a different way to do it or it may be that the recommended way
 is to refer to `_db`. So let's wait and see how it pans out (you may wish
 to follow up with the MySQLdb project and see if users of that module are
 meant to be using `_db` to get that information).

 Let's put this on hold until there's a release. We don't want to
 inadvertently look like we're supporting something that isn't released
 yet.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9154: Huge improvements in templates rendering

[Django]

#9154: Huge improvements in templates rendering
-+--
  Reporter:  msaelices   | Owner:  msaelices
Status:  new | Milestone:   
 Component:  Template system |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

  * stage:  Unreviewed => Design decision needed

Comment:

 It simply '''must''' be possible for this new behaviour ot be disabled (in
 fact, it should be disabled by default). You're proposing quite a large
 change in behaviour here: whenever a developer changes a template to fix a
 typo or something, the web server must be restarted (in effect; whatever
 is needed to cause the Django process to restart). That is quite a change
 in operational practices for a lot of places where designers can currently
 update templates and have them rolled out without a restart being
 required.

 I'm also not amazingly happy with effectively adding a new cache here that
 tries to hold things in memory. Why not using Django's existing caching
 framework and, if you're going to do that, why not just supply a caching
 wrapperaround all existing loaders? By storing stuff in memory you are
 increasing Django's in-memory footprint (there could be hundreds or
 thousands of templates involved) and there's no way to do resource
 management -- as opposed to using a proper cache which manages the amount
 of memory it will use. The amount of memory used by the urlresolvers is
 tiny compared to templates and we cache only as  last resource because the
 overhead of the parsing was becoming unacceptably slow when it was done on
 every request. Template parsing is proportionally much faster (since you
 only have to parse the the template you requested, not potentially every
 template in the system as is the case for URL reversing).

 This whole ticket feels like something designed for a small-scale
 situation that simply won't scale well. I'm still -1 on the proposed
 implementation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6652: Allow 'clean()' to specify the wrong field

[Django]

#6652: Allow 'clean()' to specify the wrong field
--+-
  Reporter:  Daniele Varrazzo <[EMAIL PROTECTED]>  | Owner:  
nobody  
Status:  reopened | Milestone:  
post-1.0
 Component:  Forms|   Version:  SVN 

Resolution:   |  Keywords:  
feature 
 Stage:  Design decision needed   | Has_patch:  1   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by rfugger):

 I just had to fiddle with Form._errors to solve this problem and I think
 being able to direct an error to a specific field using ValidationError is
 by far more elegant and useful.  Please adopt this solution.  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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8966: {% if "x"|length_is:n %} always evaluates True

[Django]

#8966: {% if "x"|length_is:n %} always evaluates True
-+--
  Reporter:  Thomas Steinacher <[EMAIL PROTECTED]>  | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  Template system |   Version:  SVN  
 
Resolution:  |  Keywords:   
 
 Stage:  Ready for checkin   | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by SmileyChris):

  * stage:  Unreviewed => Ready for checkin

Comment:

 Removal of is_safe is the right thing to do. It's a gotcha though -- a
 note explaining that `is_safe` shouldn't be used if you're relying on a
 non-string return object in `docs/howto/custom-template-tags.txt` would be
 useful.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8650: request.path_info is not documented

[Django]

#8650: request.path_info is not documented
+---
  Reporter:  dc | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

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

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9277: The "Reference" link on www.djangoproject.com front page gives a 404

[Django]

#9277: The "Reference" link on www.djangoproject.com front page gives a 404
--+-
  Reporter:  anonymous| Owner:  nobody
Status:  closed   | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:  duplicate|  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

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

Comment:

 Duplicate of #9246 (as were #9250, #9251, #9265, #9271 ...)

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8571: comment framework throws obscure exception in {% comment_form_target %}

[Django]

#8571: comment framework throws obscure exception in {% comment_form_target %}
--+-
  Reporter:  [EMAIL PROTECTED] | Owner:  nobody 
 
Status:  closed   | Milestone:  post-1.0

 Component:  django.contrib.comments  |   Version:  1.0 

Resolution:  worksforme   |  Keywords:  comment, 
comment_form_target
 Stage:  Unreviewed   | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by russellm):

 FYI - this problem was also reported as #9038, which has been fixed on the
 trunk and 1.0.X branch.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8652: Multiline tags and tag escape tags

[Django]

#8652: Multiline tags and tag escape tags
-+--
  Reporter:  Michael Manfre <[EMAIL PROTECTED]>  | Owner:  
nobody  
Status:  new | Milestone:   
   
 Component:  Template system |   Version:  SVN  
   
Resolution:  |  Keywords:  
escape multiline
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by SmileyChris):

  * stage:  Unreviewed => Design decision needed

Comment:

 Multi-line tags have been poo-pooed in the past (#3888) but I can see how
 it's important for this functionality.

 Personally I'm -0 about the need for such a raw escape tag, but I'll pass
 it through a design decision.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9277: The "Reference" link on www.djangoproject.com front page gives a 404

[Django]

#9277: The "Reference" link on www.djangoproject.com front page gives a 404
--+-
  Reporter:  anonymous| Owner:  nobody
Status:  new  | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by anonymous):

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

Comment:

 Looks like the "Using Django" link does as well.

 Both of these are the links under Documentation.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9278: Geographic Admin doesn't show vector overlay when LANGUAGE_BIDI is set

[Django]

#9278: Geographic Admin doesn't show vector overlay when LANGUAGE_BIDI is set
-+--
 Reporter:  jbronn   |   Owner:  jbronn
   Status:  new  |   Milestone:  post-1.0  
Component:  GIS  | Version:  1.0   
 Keywords:  gis rtl  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The vector overlay fails to display for when `LANGUAGE_BIDI=True` --
 right-to-left languages like Arabic and Hebrew.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8501: It is not possible to save file opened by urllib2.urlopen

[Django]

#8501: It is not possible to save file opened by urllib2.urlopen
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  anonymous   
Status:  new   | Milestone:  post-1.0
 Component:  File uploads/storage  |   Version:  SVN 
Resolution:|  Keywords:  urllib, file
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by SmileyChris):

 Interesting. It seems this is more useful than just for urlopen - it
 allows saving file objects (and stringio streams) directly too. In fact,
 I'd write urlopen off as a side-effect and rejigg the patch tests to just
 use `open()`

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9277: The "Reference" link on www.djangoproject.com front page gives a 404

[Django]

#9277: The "Reference" link on www.djangoproject.com front page gives a 404
-+--
 Reporter:  anonymous|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Django Web site  | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The "Reference" link on www.djangoproject.com front page gives a 404

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9276: class="inline-related " for stacked inline editables in admin has trailing space

[Django]

#9276: class="inline-related " for stacked inline editables in admin has 
trailing
space
--+-
 Reporter:  [EMAIL PROTECTED]|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I needed to view the source for an admin webpage with a stacked inline
 editable in it and noticed that the css class name "inline-related " has a
 trailing space.

 The problem seems to be here <
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/edit_inline/stacked.html#L8
 >.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4604: session-based messages

[Django]

#4604: session-based messages
--+-
  Reporter:  Sean Patrick Hogan <[EMAIL PROTECTED]>  | Owner:  
SmileyChris
Status:  new  | Milestone:  
   
 Component:  Contrib apps |   Version:  
SVN
Resolution:   |  Keywords:  
   
 Stage:  Accepted | Has_patch:  
1  
Needs_docs:  0|   Needs_tests:  
0  
Needs_better_patch:  1|  
--+-
Changes (by SmileyChris):

  * summary:  Message Passing For Anonymous Users => session-based messages

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7510: ModelAdmin should be able to use a non-default manager

[Django]

#7510: ModelAdmin should be able to use a non-default manager
-+--
  Reporter:  tom | Owner:  Alex
Status:  new | Milestone:  post-1.0
 Component:  django.contrib.admin|   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

  * owner:  nobody => Alex

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9258: Admin ForeignKeyRawIdWidget uses wrong manager for label lookup

[Django]

#9258: Admin ForeignKeyRawIdWidget uses wrong manager for label lookup
+---
  Reporter:  nullie | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * needs_tests:  0 => 1

Comment:

 Add on a regression test and it's good to go.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9266: Update simplejson to 2.0.1

[Django]

#9266: Update simplejson to 2.0.1
+---
  Reporter:  msaelices  | Owner:  nobody
Status:  new| Milestone:
 Component:  Serialization  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9272: contrib.admin.sites should use path_info

[Django]

#9272: contrib.admin.sites should use path_info
---+
  Reporter:  anonymous | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  django.contrib.admin  |   Version:  1.0
 
Resolution:  invalid   |  Keywords:  site.root 
mod_python
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

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

Comment:

 I'm pretty sure that using `request.path` is correct in this circumstance.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8650: request.path_info is not documented

[Django]

#8650: request.path_info is not documented
+---
  Reporter:  dc | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by SmileyChris):

 Note that most user code should *not* use `request.path_info`. The only
 case when it should be used is if the code deals directly with url
 resolving.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9199: Common middleware PREPEND_WWW broken

[Django]

#9199: Common middleware PREPEND_WWW broken
-+--
  Reporter:  gonz| Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by gonz):

  * needs_tests:  1 => 0

Comment:

 Added some simple test cases.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9006: QuerySet indexing by __getitem__ gets wrong answer in edge cases

[Django]

#9006: QuerySet indexing by __getitem__ gets wrong answer in edge cases
-+--
  Reporter:  smoluf  | Owner:  mtredinnick
Status:  assigned| Milestone: 
 Component:  Core framework  |   Version:  1.0
Resolution:  |  Keywords:  queryset index race
 Stage:  Unreviewed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by john):

 This may just be due to the fact that LIMIT queries without ORDER BY
 aren't guaranteed to return consistent result sets. The problem may be
 specific to PostgreSQL (see http://www.postgresql.org/docs/8.3/interactive
 /queries-limit.html); I haven't had time to research the other supported
 databases.

 This patch doesn't break anything, according to runtests, and it solved
 the problem I was having in the admin interface (see #9076).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9275: ORA-01830 date format picture ends before converting entire input... admin

[Django]

#9275: ORA-01830 date format picture ends before converting entire input... 
admin
---+
  Reporter:  hollerith | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.0

Resolution:|  Keywords:  oracle 
date formats
 Stage:  Unreviewed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by hollerith <[EMAIL PROTECTED]>):

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

Comment:

 Both files are the same:

 429c429
 < cursor.execute("ALTER SESSION SET NLS_DATE_FORMAT = '-
 MM-DD' "
 ---
 > cursor.execute("ALTER SESSION SET NLS_DATE_FORMAT = '-
 MM-DD HH24:MI:SS' "

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9275: ORA-01830 date format picture ends before converting entire input... admin

[Django]

#9275: ORA-01830 date format picture ends before converting entire input... 
admin
--+-
 Reporter:  hollerith |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  oracle date formats   |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Doing: Porting a legacy application on Oracle 10g.
 Symptom: The admin change interface reported this error on Datetimefields.
 Solution:I found the 'works for me' at least was to alter the
 NLS_DATE_FORMAT in backend/oracle/base.py to include the time in the
 correct format to match django format (i.e. no fractions).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4924: Loading of compressed fixtures

[Django]

#4924: Loading of compressed fixtures
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  jdunck

Status:  assigned| Milestone:   
 
 Component:  Serialization   |   Version:  SVN  
 
Resolution:  |  Keywords:  compression, 
fixtures, feature
 Stage:  Ready for checkin   | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by jdunck):

  * stage:  Accepted => Ready for checkin

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4924: Loading of compressed fixtures

[Django]

#4924: Loading of compressed fixtures
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  jdunck

Status:  assigned| Milestone:   
 
 Component:  Serialization   |   Version:  SVN  
 
Resolution:  |  Keywords:  compression, 
fixtures, feature
 Stage:  Accepted| Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by jdunck):

  * owner:  nobody => jdunck
  * needs_better_patch:  1 => 0
  * status:  new => assigned
  * needs_tests:  1 => 0
  * needs_docs:  1 => 0

Comment:

 I've uploaded a new patch addressing the concerns russellm raised in his
 09/13/07 comment.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9269: get_or_create having issues

[Django]

#9269: get_or_create having issues
---+
  Reporter:  [EMAIL PROTECTED]| Owner:  nobody  
 
Status:  new   | Milestone:  post-1.0   
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
get_or_create
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by [EMAIL PROTECTED]):

 sorry the view code is http://dpaste.com/81854/ (was very tired :) ).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9274: Support MySQLdb >= 1.3.0

[Django]

#9274: Support MySQLdb >= 1.3.0
---+
 Reporter:  Dave St.Germain <[EMAIL PROTECTED]>  |   Owner:  nobody
   Status:  new|   Milestone:   
 
Component:  Database layer (models, ORM)   | Version:  1.0  
 
 Keywords:  mysqldb|   Stage:  
Unreviewed
Has_patch:  1  |  
---+
 [http://mysql-python.sourceforge.net/ MySQL-python] version 1.3.0 and
 greater has moved two functions.  This patch enables support for the
 latest MySQLdb module.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9076: Inline forms can result in a "Please correct the errors below." message with no errors listed.

[Django]

#9076: Inline forms can result in a "Please correct the errors below." message
with no errors listed.
-+--
  Reporter:  coady   | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by john):

 I think anonymous is right and this is the same problem as in #9006. I
 attached a patch to that ticket that applies a default ordering to
 querysets if necessary before slicing or indexing them.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8571: comment framework throws obscure exception in {% comment_form_target %}

[Django]

#8571: comment framework throws obscure exception in {% comment_form_target %}
--+-
  Reporter:  [EMAIL PROTECTED] | Owner:  nobody 
 
Status:  closed   | Milestone:  post-1.0

 Component:  django.contrib.comments  |   Version:  1.0 

Resolution:  worksforme   |  Keywords:  comment, 
comment_form_target
 Stage:  Unreviewed   | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by palewire):

 I encountered this problem while porting from 0.96 to 1.0, but was able to
 fix it by making sure my root urls.py was modified from:

 {{{
 (r'^comments/', include('django.contrib.comments.urls.comments')),
 }}}
 to:

 {{{
 (r'^comments/', include('django.contrib.comments.urls')),
 }}}

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9262: Memory leak in django.utils.version.get_svn_revision

[Django]

#9262: Memory leak in django.utils.version.get_svn_revision
+---
  Reporter:  semenov| Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Daniel Pope <[EMAIL PROTECTED]>):

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

Comment:

 Python files are automatically closed when the reference count drops to
 zero, which happens immediately in this case.

 For example:

 {{{
 >>> import os
 >>> f = open('foo')
 >>> f.fileno()
 3
 >>> os.fstat(3)
 (33188, 4672869, 65024L, 1, 1000, 1000, 5111, 1222865095, 1217326625,
 1217326625)
 >>> del f
 >>> os.fstat(3)
 Traceback (most recent call last):
   File "", line 1, in 
 OSError: [Errno 9] Bad file descriptor
 }}}

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9273: Breadcrumbs refactor in newforms-admin

[Django]

#9273: Breadcrumbs refactor in newforms-admin
--+-
 Reporter:  erny  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The code to create breadcrumbs is duplicated in all templates.

 In index.html and app_index.html, app.name.title is used (with blocktrans
 which tries to translate "%(name)s", nonsense) , and application names can
 not be translated.

 In change_form.html, change_list.html, delete_confirmation.html and
 object_list.html `{{ app_label|capfirst|escape }}` is used.

 This is not DRY. Perhaps, breadcrumbs could be calculated in view
 functions and send to the templates within the context. There should be a
 way for the user to change the generated breadcrumbs.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9271: http://docs.djangoproject.com/en/dev/ is a bad link

[Django]

#9271: http://docs.djangoproject.com/en/dev/ is a bad link
--+-
  Reporter:  anonymous| Owner:  nobody
Status:  closed   | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:  duplicate|  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 Duplicate of #9265, #9251, #9250, #9246... please search the archive
 before opening new tickets

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9207: Failing test code when using contenttypes app.

[Django]

#9207: Failing test code when using contenttypes app.
+---
  Reporter:  oliverandrich  | Owner:  nobody
Status:  new| Milestone:
 Component:  Contrib apps   |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 Ok, I've got a workaround. If you replace:
 {{{
 INSTALLED_APPS = (
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'testapp'
 )
 }}}
 with:
 {{{
 INSTALLED_APPS = (
 'django.contrib.contenttypes',
 'django.contrib.auth',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'testapp'
 )
 }}}

 i.e., make sure that contenttypes appears before auth in the INSTALLED
 APPS, the problem seems to resolve itself.

 For those interested: flush removes the underlying contenttype objects,
 but the cache isn't flushed until the contenttypes post_syncdb handler is
 executed. The auth module accesses the cache, sees a stale object, and so
 doesn't create a new content type. When the auth module tries to save a
 permission against a stale cache object, the save fails.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9269: get_or_create having issues

[Django]

#9269: get_or_create having issues
---+
  Reporter:  [EMAIL PROTECTED]| Owner:  nobody  
 
Status:  new   | Milestone:  post-1.0   
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
get_or_create
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Old description:

> when i used get_or_create """p, created =
> Inventory.objects.get_or_create(product = pr, location = lo, storage_type
> = storagetype)
>  if created:
> p.amount = amount1
> p.save()
>  else:
> form.save()"""
> it would fail on created, and then it would save the form and make 2
> records in the database the second time it would give me a error that it
> found 2 of the same record
>
> the model and form file: http://dpaste.com/81855/
> the product model file:  http://dpaste.com/81866/
> the view code: http://dpaste.com/81855/
>
> the code that works: http://dpaste.com/81867/

New description:

 when i used get_or_create

 {{{
 p, created = Inventory.objects.get_or_create(product = pr, location =
 lo, storage_type = storagetype)
 if created:
 p.amount = amount1
 p.save()
 else:
 form.save()
 }}}

 it would fail on created, and then it would save the form and make 2
 records in the database the second time it would give me a error that it
 found 2 of the same record

 the model and form file: http://dpaste.com/81855/

 the product model file:  http://dpaste.com/81866/

 the view code: http://dpaste.com/81855/

 the code that works: http://dpaste.com/81867/

Comment (by kmtracey):

 Reformatted description.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9110 - in django/trunk: django/core/management django/core/management/commands docs/ref tests

[noreply]

Author: russellm
Date: 2008-10-02 07:57:13 -0500 (Thu, 02 Oct 2008)
New Revision: 9110

Modified:
   django/trunk/django/core/management/base.py
   django/trunk/django/core/management/commands/flush.py
   django/trunk/django/core/management/commands/loaddata.py
   django/trunk/django/core/management/commands/makemessages.py
   django/trunk/django/core/management/commands/syncdb.py
   django/trunk/django/core/management/commands/test.py
   django/trunk/django/core/management/commands/testserver.py
   django/trunk/docs/ref/django-admin.txt
   django/trunk/docs/ref/signals.txt
   django/trunk/tests/runtests.py
Log:
Promoted --verbosity to be a top level option for all management commands. Also 
added -v as a consistent short form of --verbosity. This is mostly to save 
Malcolm's poor arthritic fingers.


Modified: django/trunk/django/core/management/base.py
===
--- django/trunk/django/core/management/base.py 2008-10-01 17:26:40 UTC (rev 
9109)
+++ django/trunk/django/core/management/base.py 2008-10-02 12:57:13 UTC (rev 
9110)
@@ -121,6 +121,9 @@
 """
 # Metadata about this command.
 option_list = (
+make_option('-v', '--verbosity', action='store', dest='verbosity', 
default='1',
+type='choice', choices=['0', '1', '2'],
+help='Verbosity level; 0=minimal output, 1=normal output, 2=all 
output'),
 make_option('--settings',
 help='The Python path to a settings module, e.g. 
"myproject.settings.main". If this isn\'t provided, the DJANGO_SETTINGS_MODULE 
environment variable will be used.'),
 make_option('--pythonpath',
@@ -209,7 +212,7 @@
 from django.utils import translation
 translation.activate('en-us')
 except ImportError, e:
-# If settings should be available, but aren't, 
+# If settings should be available, but aren't,
 # raise the error and quit.
 sys.stderr.write(self.style.ERROR(str('Error: %s\n' % e)))
 sys.exit(1)

Modified: django/trunk/django/core/management/commands/flush.py
===
--- django/trunk/django/core/management/commands/flush.py   2008-10-01 
17:26:40 UTC (rev 9109)
+++ django/trunk/django/core/management/commands/flush.py   2008-10-02 
12:57:13 UTC (rev 9110)
@@ -4,9 +4,6 @@
 
 class Command(NoArgsCommand):
 option_list = NoArgsCommand.option_list + (
-make_option('--verbosity', action='store', dest='verbosity', 
default='1',
-type='choice', choices=['0', '1', '2'],
-help='Verbosity level; 0=minimal output, 1=normal output, 2=all 
output'),
 make_option('--noinput', action='store_false', dest='interactive', 
default=True,
 help='Tells Django to NOT prompt the user for input of any kind.'),
 )

Modified: django/trunk/django/core/management/commands/loaddata.py
===
--- django/trunk/django/core/management/commands/loaddata.py2008-10-01 
17:26:40 UTC (rev 9109)
+++ django/trunk/django/core/management/commands/loaddata.py2008-10-02 
12:57:13 UTC (rev 9110)
@@ -10,11 +10,6 @@
 from sets import Set as set   # Python 2.3 fallback
 
 class Command(BaseCommand):
-option_list = BaseCommand.option_list + (
-make_option('--verbosity', action='store', dest='verbosity', 
default='1',
-type='choice', choices=['0', '1', '2'],
-help='Verbosity level; 0=minimal output, 1=normal output, 2=all 
output'),
-)
 help = 'Installs the named fixture(s) in the database.'
 args = "fixture [fixture ...]"
 
@@ -28,15 +23,15 @@
 
 verbosity = int(options.get('verbosity', 1))
 show_traceback = options.get('traceback', False)
-
-# commit is a stealth option - it isn't really useful as 
+
+# commit is a stealth option - it isn't really useful as
 # a command line option, but it can be useful when invoking
-# loaddata from within another script. 
+# loaddata from within another script.
 # If commit=True, loaddata will use its own transaction;
 # if commit=False, the data load SQL will become part of
 # the transaction in place when loaddata was invoked.
 commit = options.get('commit', True)
-
+
 # Keep a count of the installed objects and fixtures
 fixture_count = 0
 object_count = 0
@@ -151,7 +146,7 @@
 transaction.rollback()
 transaction.leave_transaction_management()
 return
-
+
 # If we found even one object in a fixture, we need to reset the
 # database sequences.
 if object_count > 0:
@@ -161,7 +156,7 @@
 print "Resetting sequences"
 for line in sequence_sql:
 

Re: [Django] #8733: filesizeformat filter units unclear

[Django]

#8733: filesizeformat filter units unclear
-+--
  Reporter:  akaihola| Owner:  nobody  
Status:  closed  | Milestone:  post-1.0
 Component:  Template system |   Version:  SVN 
Resolution:  wontfix |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 There isn't really a big need to put all this into Django. The current
 filters are useful enough for rough size displays. If you want something
 else, it is the work of three minutes to write your own filter or download
 somebody else's. Whilst I realise there a ambiguities here, that's just
 the point: these terms are unfortunately ambiguous (and the IEC prefixes
 have never taken off in the practical world). Having two or three
 different ways to say the same thing is not going to make things any
 easier for people programming with Django.

 So let's not worry about including this into core.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8733: filesizeformat filter units unclear

[Django]

#8733: filesizeformat filter units unclear
-+--
  Reporter:  akaihola| Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Template system |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by Semmel):

 Just because Windows does it says nothing because Windows does so much
 "just plain wrong". ;) But well - i think you and Wikipedia are right. So
 there should be two versions, one for SI scale and one for IEC scale. I've
 just checked you patch - i'm not sure yet if filesize and memorysize are
 fitting names. I'll think about it. So far: Keep up the good work. :)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9269: get_or_create having issues

[Django]

#9269: get_or_create having issues
---+
  Reporter:  [EMAIL PROTECTED]| Owner:  nobody  
 
Status:  new   | Milestone:  post-1.0   
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
get_or_create
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by kenkam):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9271: http://docs.djangoproject.com/en/dev/ is a bad link

[Django]

#9271: http://docs.djangoproject.com/en/dev/ is a bad link
-+--
 Reporter:  anonymous|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Django Web site  | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 http://docs.djangoproject.com/en/dev/ sends me to a 404.

 http://docs.djangoproject.com/en/dev// (note the trailing slash) works
 fine.

 This looks like a 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9270: Docs: FORCE_SCRIPT_NAME Syntax

[Django]

#9270: Docs: FORCE_SCRIPT_NAME Syntax
---+
 Reporter:  guettli|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Please add to docs/ref/settings.txt

 FORCE_SCRIPT_NAME ...
 If set, the string should start with a slash but end without slash. E.g.
 /my_wsgi_scriptalias

 I have no sphinx build environment. If I had, I would supply a 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7930: FORCE_SCRIPT_NAME does not work with dev server

[Django]

#7930: FORCE_SCRIPT_NAME does not work with dev server
-+--
  Reporter:  ElliottM| Owner:  nobody
Status:  new | Milestone:
 Component:  HTTP handling   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by guettli):

 * cc: [EMAIL PROTECTED] (added)
  * has_patch:  0 => 1

Comment:

 I can reproduce this. Patch attached.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #689: Honor Web server provided authentication

[Django]

#689: Honor Web server provided authentication
+---
  Reporter:  [EMAIL PROTECTED]| Owner:  telenieko
Status:  assigned   | Milestone:   
 Component:  Core framework |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by guettli):

 This ticket is on the [wiki:Version1.1Features] list.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9269: get_or_create having issues

[Django]

#9269: get_or_create having issues
--+-
 Reporter:  [EMAIL PROTECTED]|   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  get_or_create |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 when i used get_or_create """p, created =
 Inventory.objects.get_or_create(product = pr, location = lo, storage_type
 = storagetype)
  if created:
 p.amount = amount1
 p.save()
  else:
 form.save()"""
 it would fail on created, and then it would save the form and make 2
 records in the database the second time it would give me a error that it
 found 2 of the same record

 the model and form file: http://dpaste.com/81855/
 the product model file:  http://dpaste.com/81866/
 the view code: http://dpaste.com/81855/

 the code that works: http://dpaste.com/81867/

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---