[Django] #19299: Foreign keys using to_field and having legitimate empty string values fail with NULL errors

[Django]

#19299: Foreign keys using to_field and having legitimate empty string values 
fail
with NULL errors
--+
 Reporter:  evan@…|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 If one table references another table with a foreign
 key using a to_field that's a string, and the target column has an empty
 string as a possible value, the ORM would remap it to None, and thus
 NULL, which is not the same, and which breaks the relation.

 
[https://github.com/tunixman/django/commit/45f1da6aea8921c55dfc2f5618d03c800d3fa803
 Minimal test case and fix]

-- 
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] #19297: refactor settings setup code

[Django]

#19297: refactor settings setup code
--+
 Reporter:  ptone |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by ptone):

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


Comment:

 So after poking around this area I've concluded two things:

 1) the savings gained aren't worth the gymnastics of a refactor here
 2) configure really is doing a different enough thing to stay different

-- 
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] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
--+
 Reporter:  dstufft   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ptone):

 So going another round on this - if we wanted to make Django "special" and
 buck what core-python decided WRT DeprecationWarnings being ignored, I
 would be suggesting putting the simplefilter in django/__init__ as the
 place to "change the runtime".  However there is a strong argument against
 making Django special in the Python ecosphere. Instead if we consider that
 when DEBUG true - we are running in a "special" mode, and so do special
 things, that would be more reasonable.
 I'm going to step back from the idea of putting the simplefilter in
 manage.py as something that is harder to disable - and generally not going
 to gain all that much in terms of early deprecations.

 The main deprecations missed will be those directly related to settings
 themselves, but the only way around that is to deviate farther toward the
 path of being "special"

 A remaining question - and it is minor, is whether or not to have the
 simplefilter entwined with the logging setup.

 The patch from Claude is very reasonable, the only other way to get to a
 similar state would be something like:

 https://github.com/ptone/django/compare/ticket/18985-loud-deprecation

 The only thing in favor of that is if you were to do something custom with
 the console handler, and didn't want that to be applied to warnings -
 you'd have to de-couple them.  But at that point it would be just as easy
 to also change the py.warnings logger.

 So I suppose I'm slightly more in favor of going through logging.

-- 
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] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:  pegler@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite spatialite| Triage Stage:  Accepted
  LiveServerTestCase |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by julien):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19298: MultiValueField should override __deepcopy__

[Django]

#19298: MultiValueField should override __deepcopy__
-+--
 Reporter:  nick.phillips@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by nwp):

 * cc: nwp (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

[Django] #19298: MultiValueField should override __deepcopy__

[Django]

#19298: MultiValueField should override __deepcopy__
-+
 Reporter:  nick.phillips@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 MultiValueField needs to override the default inherited from Field, as it
 needs to deep-copy subfields:

 {{{
 def __deepcopy__(self, memo):
 result = copy.copy(self)
 memo[id(self)] = result
 result.fields = copy.deepcopy(self.fields, memo)
 result.widget = copy.deepcopy(self.widget, memo)
 result.validators = self.validators[:]
 return result
 }}}

 or

 {{{
 def __deepcopy__(self, memo):
 result = super(MultiValueField, self).__deepcopy__(memo)
 result.fields = copy.deepcopy(self.fields, memo)
 return result
 }}}

 should be added to MultiValueField, if I'm right.

 Without this, any "MyClass" that subclasses MultiValueField and uses
 subfields with complex attributes (e.g. ChoiceField's "choices") will fail
 when re-used within the same view.

-- 
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] #15015: Mixing read-only with ability to add new instances using a FormSet

[Django]

#15015: Mixing read-only with ability to add new instances using a FormSet
-+-
 Reporter:  coleifer |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by wiml):

 * cc: wiml@… (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] #19297: refactor settings setup code

[Django]

#19297: refactor settings setup code
+
   Reporter:  ptone |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 There is an increasing amount of code duplication in
 conf.__init__.LazySettings between _setup and configure

 There are some differences in the way the actual settings holder is setup
 - but there should be a way to refactor this so that _setup calls
 configure, and put the common code there.

-- 
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] #19295: runserver --insecure doesn't work with DEBUG False and CachedStaticFilesStorage

[Django]

#19295: runserver --insecure doesn't work with DEBUG False and
CachedStaticFilesStorage
-+-
 Reporter:  Apreche  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

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


-- 
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] #19295: runserver --insecure doesn't work with DEBUG False and CachedStaticFilesStorage

[Django]

#19295: runserver --insecure doesn't work with DEBUG False and
CachedStaticFilesStorage
-+-
 Reporter:  Apreche  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

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


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

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

Re: [Django] #19267: 1.4.1 PDF Table of Contents links broken

[Django]

#19267: 1.4.1 PDF Table of Contents links broken
-+-
 Reporter:  michael.amie@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  PDF, Documentation,  | Triage Stage:  Accepted
  Links  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by timo):

 This may be a problem with readthedocs -- I just rebuilt the docs for
 1.3.X, 1.4.X, and latest there and now the TOC doesn't appear on any of
 them.  However, when I build the docs locally (tested master and 1.4.X)
 the TOC does appear.

-- 
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] #16779: Add a tutorial for first time Django contributors

[Django]

#16779: Add a tutorial for first time Django contributors
---+
 Reporter:  taavi223   |Owner:  taavi223
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by ptone):

 OK - sorry or the late feedback - but better late than never.

 I don't think we want to encourage pip -e github-url as a pattern - this
 puts the git checkout inside the virtualenv

 virtualenv's are something that should be possible to blow away - and
 having a repo where you are doing development work in there isn't a good
 pattern to demonstrate

 Instead following the line to git clone, the virtualenv pip instruction
 should be:

 pip -e /path/to/your/local/clone

 This will create the live link in the virtualenv, but keep the dev repo
 wherever you want on disk.

 
--

 Suggested rewording:

 151 +be using an older revision of Django from before that ticket's
 patch was
 152 +applied.

 so we'll rewind Django's version history in git to before that ticket's
 patch was applied

 Helps clarify that all older revisions are in the one repo.

 
--

 I'm reluctantly OK with showing the diff + trac attachment approach, but
 I'd like to advocate for the git workflow just a bit more strongly.  I
 also think we need to help people get their upstaged changes cleared out
 for future work.

 replace:

 however, you can also :doc:`submit pull requests on Github
 558 +`.

 with:

 however, since we are using git - adopting a more `git oriented workflow
 ` is recommended.
 To get your git branch back to a good starting point, we can do the
 following since we never committed our changes locally:

 git reset --hard head
 git checkout 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] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:   |  Owner:  nobody
  pegler@…   | Status:  new
 Type:   |Version:  1.4
  Uncategorized  |   Keywords:  sqlite spatialite
Component:  Testing  |  LiveServerTestCase
  framework  |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 Like the title says, if the database backend is set to
 'django.contrib.gis.db.backends.spatialite' instead of
 'django.db.backends.sqlite3' it doesn't properly share the connection with
 the new threads when using LiveServerTestCase.  See:
 
https://github.com/django/django/blob/82b3e6ffcb9d810cc0e3ec27d25f89ce1fd525e0/django/test/testcases.py#L1080

-- 
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] #19294: Strange WSGIRequest behavior

[Django]

#19294: Strange WSGIRequest behavior
---+--
 Reporter:  gael@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  wsgi   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by gael@…):

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


Comment:

 In fact, even if this is a weird behaviour. It looks like this is allowed
 byt the rfc...

-- 
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] #19252: Install from wheel package

[Django]

#19252: Install from wheel package
--+
 Reporter:  Alex Morega   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Release blocker   |   Resolution:  invalid
 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):

 This bug is exactly the same thing that happens, and is currently
 compensated for, when building bdist_wininst installers. This should be a
 hint that data files are a problem.

 Why not fix it for everyone by disusing the data files feature of
 distutils, regardless of sys.argv?

-- 
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] #19239: Provide examples in the ref docs for Generic date views

[Django]

#19239: Provide examples in the ref docs for Generic date views
--+
 Reporter:  pydanny   |Owner:  pydanny
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timo):

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

[Django] #19295: runserver --insecure doesn't work with DEBUG False and CachedStaticFilesStorage

[Django]

#19295: runserver --insecure doesn't work with DEBUG False and
CachedStaticFilesStorage
-+
 Reporter:  Apreche  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 How to reproduce:

 Enable the CachedStaticFilesStorage in your settings and turn DEBUG off.

 {{{
 DEBUG = False

 STATICFILES_STORAGE =
 'django.contrib.staticfiles.storage.CachedStaticFilesStorage'
 }}}

 Turn on the runserver with the insecure flag

 {{{ $ python manage.py runserver --insecure }}}

 Visit your runserver in your browser, and the static files will not load.
 When using the default
 django.contrib.staticfiles.storage.StaticFilesStorage the static files
 will load.

 The reason is because of this section in contrib/staticfiles.storage.py

 {{{
 100 def url(self, name, force=false):
 101 """
 102 Returns the real URL in DEBUG mode.
 103 """
 104 if settings.DEBUG and not force:
 105 hashed_name, fragment = name, ''
 106 else:
 }}}

 When DEBUG is False, the automatic static file serving in runserver is
 disabled. But using runserver with --insecure will re-enable it. Because
 the CachedStaticFilesStorage only looks at the DEBUG flag, it will not
 work properly in this scenario. Perhaps that force parameter could be set
 to True when the --insecure flag is passed to runserver?

 Yes, this is an extremely rare and low-priority edge case, but still a
 bug.

 It's also not clear what the expected behavior is when both the --nostatic
 and --insecure flags are passed to runserver simultaneously. They sort of
 cancel each other out. Personally I feel the nostatic should take
 priority.

-- 
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] #18925: Exception information should be localized and passed to got_request_exception signal handlers

[Django]

#18925: Exception information should be localized and passed to
got_request_exception signal handlers
---+--
 Reporter:  obeattie   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:  wontfix
 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 obeattie):

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


Comment:

 In response to my posts on the mailing list, this has actually been fixed
 
[https://github.com/SiteSupport/gevent/commit/554ed446db75ed6b15f277ccc0094140d2b03e88
 in gevent], so closing this.

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

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

[Django] #19294: Strange WSGIRequest behavior

[Django]

#19294: Strange WSGIRequest behavior
---+
 Reporter:  gael@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  HTTP handling  |Version:  1.4
 Severity:  Normal |   Keywords:  wsgi
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Looks like QUERY_STRING parsing has some problems:

 {{{
 >>> from django.core.handlers.wsgi import WSGIRequest
 >>> r = WSGIRequest(dict(QUERY_STRING='toto=2;1', REQUEST_METHOD='GET',
 **{'wsgi.input':None}))
 >>> r.GET['1']
 u''
 >>> r.GET
 
 >>> r = WSGIRequest(dict(QUERY_STRING='foo=1&bar=1;foo',
 REQUEST_METHOD='GET', **{'wsgi.input':None}))
 >>> r.GET
 
 }}}

 Is that really expected ?

-- 
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] #19239: Provide examples in the ref docs for Generic date views

[Django]

#19239: Provide examples in the ref docs for Generic date views
--+
 Reporter:  pydanny   |Owner:  pydanny
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by pydanny):

 Submitted pull request for this ticket at
 https://github.com/django/django/pull/517.

 Work performed with @citadelgrad / Scott Nixon of
 https://github.com/citadelgrad.

-- 
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] #19293: Update of czech date and time formats

[Django]

#19293: Update of czech date and time formats
---+--
 Reporter:  vzima  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Translations   |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

 * cc: macek@… (added)


Comment:

 It would be nice if this could be confirmed by the Czech translation
 coordinator on Transifex (Vlada Macek).

-- 
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] #19292: syncdb ignores umask when creating a sqlite database

[Django]

#19292: syncdb ignores umask when creating a sqlite database
-+-
 Reporter:  pitrou@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 A quick search brings up this thread: http://www.mail-archive.com/sqlite-
 us...@sqlite.org/msg59080.html

 Apparently it's a bug in SQLite.

 The same bug was reported against PHP and rejected for the same reason:
 https://bugs.php.net/bug.php?id=31573

 It also exists in Python itself:
 {{{
 aaugustin@aaugustin ~ % python
 Python 2.7.2 (default, Jun 20 2012, 16:23:33)
 [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on
 darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> os.umask(0o002)
 18
 >>> import sqlite3
 >>> sqlite3.connect('example.db').close()
 >>> ^D
 aaugustin@aaugustin ~ % ls -l example.db
 -rw-r--r--  1 aaugustin  staff  0 14 nov 14:00 example.db
 }}}

-- 
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] #19277: LocaleMiddleware permanent redirects

[Django]

#19277: LocaleMiddleware permanent redirects
--+
 Reporter:  ppetrid@… |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by anonymous):

 Agreed on the setting. Normaly you would't want both / and /en/ indexed
 since it will split your backlinks, pagerank etc (and they'll both get
 indexed unless the developer takes further action). The agent is indeed an
 issue and when it comes to that 302 redirects are more suitable. As for
 google, I quit using them as an example the day I found google is the
 first to break their own guidelines.. :)

-- 
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] #16779: Add a tutorial for first time Django contributors

[Django]

#16779: Add a tutorial for first time Django contributors
---+
 Reporter:  taavi223   |Owner:  taavi223
 Type:  New feature|   Status:  assigned
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by timo):

 I've made the following updates based on feedback from the django-
 developers thread:

 * Recommended running tests with PYTHONPATH=.. since both Aymeric and
 Claude suggested that.
 * Removed the PYTHONPATH section since it's obsolete given the above
 * Recommended Git Bash, per Aymeric's suggestion. I don't have any
 experience with Windows to elaborate here, so if you have input, please
 chime in with suggested text.
 * Added a recommendation for virtualenv and eliminated the "advanced" in
 "For advanced users who wish to use virtualenv".

-- 
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] #19293: Update of czech date and time formats

[Django]

#19293: Update of czech date and time formats
---+--
 Reporter:  vzima  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Translations   |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by vzima):

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


Comment:

 Published also at django-cs group

 https://groups.google.com/forum/#!topic/django-cs/xERvIKC_-QA/discussion

-- 
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] #19293: Update of czech date and time formats

[Django]

#19293: Update of czech date and time formats
---+
 Reporter:  vzima  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Translations   |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Czech formats does not support date and time formats of Czech grammar,
 especially `H.M:S` and `j. n. Y`.

 I attach patch that adds support for these formats.

 Sources (Czech only):
 http://prirucka.ujc.cas.cz/?id=820
 http://prirucka.ujc.cas.cz/?id=810

-- 
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] #19277: LocaleMiddleware permanent redirects

[Django]

#19277: LocaleMiddleware permanent redirects
--+
 Reporter:  ppetrid@… |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:   => 0
 * component:  Translations => Internationalization
 * needs_tests:   => 0
 * version:  1.4 => master
 * needs_docs:   => 0
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 I don't think that a permanent redirect is always wanted. Depending on the
 user agent, the redirected URL will change. You talk about web crawlers,
 but I guess you'd better find that www.yourdomain.com is kept in the
 search index instead of www.yourdomain.com/en/.

 Google itself is using 302 redirects to redirect to country specific
 interfaces.

 I'm afraid there are no true right answer to this. We could even imagine
 using the 300 code. I'd be in favour of setting a status_code class
 attribute for LocaleMiddleware, so it is easy for subclasses to customize
 it. Accepting on this base.

-- 
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] #19289: In https://docs.djangoproject.com/en/dev/intro/tutorial02/, a sentence refers to "code from above" that doesn't exist above that sentence.

[Django]

#19289: In https://docs.djangoproject.com/en/dev/intro/tutorial02/, a sentence
refers to "code from above" that doesn't exist above that sentence.
+
 Reporter:  colinnkeenan@…  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Tim Graham ):

 In [changeset:"dea4214bb5903398b72e96a2fea24baeca8ed9f3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="dea4214bb5903398b72e96a2fea24baeca8ed9f3"
 [1.5.X] Fixed #19289 - Removed an out of place sentence in tutorial 2.

 Thanks colinnkeenan for the report.

 Backport of 2dbfa66f4d 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] dea421: [1.5.X] Fixed #19289 - Removed an out of place sen...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: dea4214bb5903398b72e96a2fea24baeca8ed9f3
  
https://github.com/django/django/commit/dea4214bb5903398b72e96a2fea24baeca8ed9f3
  Author: Tim Graham 
  Date:   2012-11-14 (Wed, 14 Nov 2012)

  Changed paths:
M docs/intro/tutorial02.txt

  Log Message:
  ---
  [1.5.X] Fixed #19289 - Removed an out of place sentence in tutorial 2.

Thanks colinnkeenan for the report.

Backport of 2dbfa66f4d 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] #19289: In https://docs.djangoproject.com/en/dev/intro/tutorial02/, a sentence refers to "code from above" that doesn't exist above that sentence.

[Django]

#19289: In https://docs.djangoproject.com/en/dev/intro/tutorial02/, a sentence
refers to "code from above" that doesn't exist above that sentence.
+
 Reporter:  colinnkeenan@…  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2dbfa66f4db54c2bbac0f160de96a91fcf39997d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2dbfa66f4db54c2bbac0f160de96a91fcf39997d"
 Fixed #19289 - Removed an out of place sentence in tutorial 2.

 Thanks colinnkeenan for the 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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 2dbfa6: Fixed #19289 - Removed an out of place sentence in...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 2dbfa66f4db54c2bbac0f160de96a91fcf39997d
  
https://github.com/django/django/commit/2dbfa66f4db54c2bbac0f160de96a91fcf39997d
  Author: Tim Graham 
  Date:   2012-11-14 (Wed, 14 Nov 2012)

  Changed paths:
M docs/intro/tutorial02.txt

  Log Message:
  ---
  Fixed #19289 - Removed an out of place sentence in tutorial 2.

Thanks colinnkeenan for the report.



-- 
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] #19292: syncdb ignores umask when creating a sqlite database

[Django]

#19292: syncdb ignores umask when creating a sqlite database
-+-
 Reporter:  pitrou@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Database layer (models, ORM) => Core (Management commands)
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #19291: Sort out deprecation of ADMIN_MEDIA_PREFIX

[Django]

#19291: Sort out deprecation of ADMIN_MEDIA_PREFIX
-+-
 Reporter:  ptone|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by jezdez):

 The admin is a contrib app which doesn't completely adhere to the
 deprecation policy.

 Also, the ADMIN_MEDIA_PREFIX setting was a crux and had a better
 alternative with STATIC_URL + /admin/ that was introduced before. The
 "accelerated deprecation" thing you mention is a new policy that wasn't
 around when I remove the setting, so it wasn't clearly mentioned as that
 in the release notes. Feel free to add it if you are so inclined.

 But for the love of god, remove it in 1.5, it was a stupid setting.

-- 
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] #18508: Bug in handling out-of-date POST data with inlineformset_factory

[Django]

#18508: Bug in handling out-of-date POST data with inlineformset_factory
+
 Reporter:  olau|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by olau):

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

[Django] #19292: syncdb ignores umask when creating a sqlite database

[Django]

#19292: syncdb ignores umask when creating a sqlite database
--+
 Reporter:  pitrou@…  |  Owner:  nobody
 Type:  Bug   | 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
--+
 My settings.py is using the `django.db.backends.sqlite3` backend, and the
 user running manage.py has umask value 0002. However, when running
 `manage.py syncdb` for the first time, the sqlite database file is created
 with access rights 0644, ignoring the user's umask value.

-- 
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] #14877: ModelFormSet.save() with a deleted form should work even if the model has already been deleted

[Django]

#14877: ModelFormSet.save() with a deleted form should work even if the model 
has
already been deleted
---+-
 Reporter:  andornaut  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3-alpha
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by olau):

 * 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] #18508: Bug in handling out-of-date POST data with inlineformset_factory

[Django]

#18508: Bug in handling out-of-date POST data with inlineformset_factory
+
 Reporter:  olau|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by olau):

 Thanks! I can see now that my description is a bit cryptic. Basically, the
 problem here is a concurrency problem.

 If you post a formset, Django is supposed to use another branch of the
 code to match each individual form with its object because you can't
 assume that a POSTed formset[i] corresponds to get_queryset()[i] - an
 element could have been added/deleted or the ordering changed.

 Unfortunately, there's a trivial bug in this logic so it fails if one of
 the elements has been deleted.

 I only noticed this because there was a Javascript bug in a site I've been
 doing maintenance for, so people would sometimes end up double-POSTing a
 delete, causing a mysterious crash. This patch and the patch in #14877
 fixed it. You can still get concurrency issues but can at least deal with
 it yourself (e.g. through form validation) since Django passes the data on
 to you rather than crashing. :)

-- 
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] #19272: gettext_lazy returns "unexpected type"

[Django]

#19272: gettext_lazy returns "unexpected type"
-+-
 Reporter:  tyrion   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Translations |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"ebafba50a418d4a444a067a3d35cea7f98a20158"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ebafba50a418d4a444a067a3d35cea7f98a20158"
 [1.5.x] Fixed #19272 -- Fixed gettext_lazy returned type on Python 2

 Thanks tyrion for the report.
 Backport of 550ddc66b 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] ebafba: [1.5.x] Fixed #19272 -- Fixed gettext_lazy returne...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: ebafba50a418d4a444a067a3d35cea7f98a20158
  
https://github.com/django/django/commit/ebafba50a418d4a444a067a3d35cea7f98a20158
  Author: Claude Paroz 
  Date:   2012-11-14 (Wed, 14 Nov 2012)

  Changed paths:
M django/utils/translation/trans_real.py
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #19272 -- Fixed gettext_lazy returned type on Python 2

Thanks tyrion for the report.
Backport of 550ddc66b 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] #19272: gettext_lazy returns "unexpected type"

[Django]

#19272: gettext_lazy returns "unexpected type"
-+-
 Reporter:  tyrion   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Translations |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"550ddc66b496473c8ee282c7ab6be5885a359d75"]:
 {{{
 #!CommitTicketReference repository=""
 revision="550ddc66b496473c8ee282c7ab6be5885a359d75"
 Fixed #19272 -- Fixed gettext_lazy returned type on Python 2

 Thanks tyrion for the 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 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 550ddc: Fixed #19272 -- Fixed gettext_lazy returned type o...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 550ddc66b496473c8ee282c7ab6be5885a359d75
  
https://github.com/django/django/commit/550ddc66b496473c8ee282c7ab6be5885a359d75
  Author: Claude Paroz 
  Date:   2012-11-14 (Wed, 14 Nov 2012)

  Changed paths:
M django/utils/translation/trans_real.py
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Fixed #19272 -- Fixed gettext_lazy returned type on Python 2

Thanks tyrion for the report.



-- 
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] #19186: fail send utf-8 email

[Django]

#19186: fail send utf-8 email
-+-
 Reporter:  alex_po  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  mail utf8 python3| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"8967906e0a38884665cf542dfb2d84b087d23d99"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8967906e0a38884665cf542dfb2d84b087d23d99"
 [1.5.x] Fixed #19186 -- Fixed sending mail with unicode content on Python
 3

 Thanks alex_po for the report and Luke Plant for the analysis.
 Backport of 1620c27936 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] 896790: [1.5.x] Fixed #19186 -- Fixed sending mail with un...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 8967906e0a38884665cf542dfb2d84b087d23d99
  
https://github.com/django/django/commit/8967906e0a38884665cf542dfb2d84b087d23d99
  Author: Claude Paroz 
  Date:   2012-11-14 (Wed, 14 Nov 2012)

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

  Log Message:
  ---
  [1.5.x] Fixed #19186 -- Fixed sending mail with unicode content on Python 3

Thanks alex_po for the report and Luke Plant for the analysis.
Backport of 1620c27936 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] #19186: fail send utf-8 email

[Django]

#19186: fail send utf-8 email
-+-
 Reporter:  alex_po  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  mail utf8 python3| Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"1620c27936718a87bbc8acce7886ef20fee2b3fe"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1620c27936718a87bbc8acce7886ef20fee2b3fe"
 Fixed #19186 -- Fixed sending mail with unicode content on Python 3

 Thanks alex_po for the report and Luke Plant for the analysis.
 }}}

-- 
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] 1620c2: Fixed #19186 -- Fixed sending mail with unicode co...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1620c27936718a87bbc8acce7886ef20fee2b3fe
  
https://github.com/django/django/commit/1620c27936718a87bbc8acce7886ef20fee2b3fe
  Author: Claude Paroz 
  Date:   2012-11-14 (Wed, 14 Nov 2012)

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

  Log Message:
  ---
  Fixed #19186 -- Fixed sending mail with unicode content on Python 3

Thanks alex_po for the report and Luke Plant for the analysis.



-- 
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] #19288: incorrect default verbose_name_plural in 1.5

[Django]

#19288: incorrect default verbose_name_plural in 1.5
-+-
 Reporter:  cdestigter   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-alpha-1
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 I find the exact same behaviour in 1.4. Reopen if you can demonstrate the
 regression.

-- 
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] #19287: Change from "e-mail" to "email" not reflected in translation files for contrib.auth

[Django]

#19287: Change from "e-mail" to "email" not reflected in translation files for
contrib.auth
--+---
 Reporter:  bmispelon |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.5-alpha-1
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  e-mail i18n   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---

Comment (by claudep):

 Yes, we will pull the translations before the release (maybe before beta
 or rc also, if time permits).

 See
 https://docs.djangoproject.com/en/dev/internals/contributing/localizing/
 for the docs.

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

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

Re: [Django] #19289: In https://docs.djangoproject.com/en/dev/intro/tutorial02/, a sentence refers to "code from above" that doesn't exist above that sentence.

[Django]

#19289: In https://docs.djangoproject.com/en/dev/intro/tutorial02/, a sentence
refers to "code from above" that doesn't exist above that sentence.
+
 Reporter:  colinnkeenan@…  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Documentation   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 This was introduced in [07abb7a6b7af2c45be553acf08d85cd2d72057ad]
 (#18715).

-- 
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] #19058: Inserting NULL value in Oracle spatial backend causes crash.

[Django]

#19058: Inserting NULL value in Oracle spatial backend causes crash.
-+-
 Reporter:  jtiai|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  gis oracle orm   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I am going to push the patch pretty much as is. Even if Oracle GIS is
 still broken after this to me it seems like one step in the right
 direction. We can't break Oracle GIS, and I can't see how this could break
 anything else. So, I will push this to 1.4.x on the grounds that this is a
 crash-fix for Oracle GIS.

-- 
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] #19287: Change from "e-mail" to "email" not reflected in translation files for contrib.auth

[Django]

#19287: Change from "e-mail" to "email" not reflected in translation files for
contrib.auth
--+---
 Reporter:  bmispelon |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.5-alpha-1
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  e-mail i18n   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---

Comment (by bmispelon):

 I see.

 The translation strings are indeed correct on transifex (I was looking at
 the files on github).

 I assume these translations will get pulled just before the release. Is
 this process documented somewhere (I looked but couldn't find any info)?

-- 
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] #19287: Change from "e-mail" to "email" not reflected in translation files for contrib.auth

[Django]

#19287: Change from "e-mail" to "email" not reflected in translation files for
contrib.auth
--+---
 Reporter:  bmispelon |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.5-alpha-1
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  e-mail i18n   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by claudep):

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


Comment:

 We could have done it at the same time as the change, but generally I
 don't like touching translation files behind the back of translators. Now
 it's too late for sure, as new translation files have been uploaded to
 Transifex and translators already began the translation process for 1.5.
 Note that the old translation is still available in Transifex as a
 suggestion, so those strings could be easily copied as the new
 translation.

 https://www.transifex.com/projects/p/django/

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

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