Re: [Django] #25259: Add Django version in a comment (hint) to auto-generated migration files

2015-08-12 Thread Django 
#25259: Add Django version in a comment (hint) to auto-generated migration files
-+--
 Reporter:  tysonclugg   |Owner:  tysonclugg
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+--

Comment (by claudep):

 At least tests should pass: http://djangoci.com/job/pull-requests-
 trusty/2966/

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.352207c2fe7272d1292f1b459c78e857%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25265: DB Backend cannot specify query class.

2015-08-12 Thread Django 
#25265: DB Backend cannot specify query class.
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 akaariai):

 Its also worth noting that there are three ways to implement nonsql
 backends:
   1. Implement Compiler
   2. Implement Query (and possibly Compiler)
   3. Implement QuerySet (and possibly Query and Compiler)

 Currently implementing a different Compiler for nonsql backend is the
 suggested approach. In principle it should work. In practice, I don't
 know. I guess the biggest problem is that when doing this, the author is
 targeting an often changing internal API.

 I'm not sure implementing Query is that much better. The API for Query
 isn't public. How about implementing QuerySet itself? Now that iterator is
 separated from QuerySet, it isn't that much more work when compared to
 just implementing Query and/or Compiler.

 For .using() incompatibility - I think we should throw an error. And the
 default backend should be used to decide what is the default queryset
 type. So, if you have default db = mongodb, other = postgres, then
 User.objects.filter(foo=bar).using('other') should throw an error, but
 User.objects.using('other').filter(foo=bar) shouldn't.

 It is also worth noting that maybe the right answer is to use different
 *models* altogether - Django's default user, permission and groups system
 for example isn't a good design for non-relational databases. If you
 control the models, then you also control the default queryset type, and
 we don't have a problem to begin with.

 I guess I am +½ to manager .get_queryset() checking the query/queryset
 class from the default backend, with the idea that objects.using('other')
 will get you the other backend's query/queryset class.

 Finally, I think whatever we come up with here, we should present the
 solution on django-developers and ask for opinions.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.d717023ecb49012421290d754ef289e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25265: DB Backend cannot specify query class.

2015-08-12 Thread Django 
#25265: DB Backend cannot specify query class.
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 techdragon):

 RE: akaariai
 --
 The situation between 'comparable' database backends should actually be
 more like what will happen if you did the same query
 {{{User.objects.filter(id=10).using('postgres')}}} with a MySQL and
 PostgreSQL backend. I can't say I've done that myself, but if it raises an
 error, it should raise an error between a sql and a nonsql backend.
 'Non comparable' backends should probably raise an error, something like
 {{{NotImplemented}}} perhaps.
 --
 RE: jarshwah
 --
 1 - This offers little improvement over a custom model that uses the Meta
 API, and overrides the save method.
 2 - This is more like what I'm thinking. While its definitely possible to
 enhance the flexibility by providing a SETTINGS powered override, I'm not
 sure that defining the 'default' query for any particular backend in the
 SETTINGS dictionary is the right way to go.
 3 - Just like suggestion 1, this doesn't improve the 'compatibility'
 situation significantly, beyond what can be done with existing mechanisms
 such as custom models using the Meta API and overriding their save
 methods.
 --

 Ideally with a database backend that supports all the correct methods, we
 should be able to run Django entirely on top of it, so that means either
 extensive modifications to contrib.user and other contrib modules, to
 support some kind of 'optional non sql path', or we need to 'fix' the
 'issues' that currently exist with this and related section of code that
 result in the public API to the ORM mandating that any Django database
 backend behave like an SQL database.

 I'm fairly sure the optimal path is shifting some of this back into the
 database backend 'layer'. Possibly creating a new "base_sql" class that
 the existing SQL database backends inherit from instead of
 {{{db.backends.base}}} and things like defining 'what is my query class'
 can be set here and shared by all the SQL backends. Otherwise we just
 implement the new behaviour in each backend.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.5d6738e351dbce6f6d65c4a9bb925b6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25259: Add Django version in a comment (hint) to auto-generated migration files

2015-08-12 Thread Django 
#25259: Add Django version in a comment (hint) to auto-generated migration files
-+--
 Reporter:  tysonclugg   |Owner:  tysonclugg
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+--

Comment (by tysonclugg):

 Replying to [comment:4 timgraham]:
 Could you please elaborate as to what improvements you were expecting?

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.22b5830a404a5b9a9b2304e717285613%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25263: How closely we should adhere to PEP 257

2015-08-12 Thread Django 
#25263: How closely we should adhere to PEP 257
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 techdragon):

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


Comment:

 I'm reopening it since I didn't get a chance to comment on the criticism
 before it was closed.
 It's worth considering that some of the things that PEP 257 recommends are
 areas beneficial to the level of documentation in the source code.

 Checks D100, D101, D102, and D103 all indicate Modules, Classes and
 Methods that have no documentation at all.
 Others are mainly about consistency and some of them are definitely of
 minimal improvement or possibly even detrimental.

 The full list is below.

 Missing Docstrings
 D100Missing docstring in public module
 D101Missing docstring in public class
 D102Missing docstring in public method
 D103Missing docstring in public function
 Whitespace Issues
 D200One-line docstring should fit on one line with quotes
 D201No blank lines allowed before function docstring
 D202No blank lines allowed after function docstring
 D2031 blank line required before class docstring
 D2041 blank line required after class docstring
 D2051 blank line required between summary line and description
 D206Docstring should be indented with spaces, not tabs
 D207Docstring is under-indented
 D208Docstring is over-indented
 D209Multi-line docstring closing quotes should be on a separate line
 D210No whitespaces allowed surrounding docstring text
 Quotes Issues
 D300Use “”“triple double quotes”“”
 D301Use r”“” if any backslashes in a docstring
 D302Use u”“” for Unicode docstrings
 Docstring Content Issues
 D400First line should end with a period
 D401First line should be in imperative mood
 D402First line should not be the function’s “signature”

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.937d3a27bb3de6c2b0f7545b171b2b7c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25268: Documentation small error on Forms - Subclassing forms.

2015-08-12 Thread Django 
#25268: Documentation small error on Forms - Subclassing forms.
-+-
 Reporter:  Alejoss  |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |
Component:  Documentation|Version:  1.8
 Severity:  Normal   |   Keywords:  Documentation, Forms
 |  Api
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Where it writes, near the end of the document, under Subclassing forms:

 "It’s possible to declaratively remove a Field inherited from a parent
 class by setting the '''name''' to be None on the subclass."

 it should write:

 "It’s possible to declaratively remove a Field inherited from a parent
 class by setting the '''value''' to be None on the subclass."

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.e6da954ac51027046062d2eaf8ea271c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25172: System checks don't respect database routers

2015-08-12 Thread Django 
#25172: System checks don't respect database routers
-+-
 Reporter:  delinhabit   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  1.7
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  system-checks| Triage Stage:  Ready for
  multi-database |  checkin
Has patch:  1|  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:"0cc059cd104cdb70340bd08e597d403d80dc42a6" 0cc059c]:
 {{{
 #!CommitTicketReference repository=""
 revision="0cc059cd104cdb70340bd08e597d403d80dc42a6"
 Fixed #25172 -- Fixed check framework to work with multiple databases.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.bef2c122c9095410f5f7a3147fb163f0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11487: Oracle encoding bug when saving more than 4000 characters

2015-08-12 Thread Django 
#11487: Oracle encoding bug when saving more than 4000 characters
-+-
 Reporter:  mdpetry  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle database  | Triage Stage:  Accepted
  nclob clob |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by RohitV24):

 We are currently experiencing the same issue while inserting large strings
 (between size 2000-4000 characters) into the Oracle database.The
 NLS_NCHAR_CHARACTERSET on our database is  AL16UTF16 which assigns 2 bytes
 for a char .From digging in a little deeper, it looks like a string is
 mapped to cx_Oracle.STRING which is then mapped to either a VARCHAR,
 NVARCHAR or LONG in Oracle and the conversion to long in case of long
 values is causing the error. It looks like the issue with 4000 characters
 was fixed by setting the input size to cx_Oracle.CLOB when it reached the
 character limit. Using 2000( for utf-16) seems to work fine and solve the
 problem. Would setting the comparison value to 1000 (taking into
 consideration other encoding formats) before setting it to CLOB be the fix
 for this issue?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b89b51fc047d22dabf54331700af6792%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25170: assertXMLEqual fails when white space is present outside XML fragment

2015-08-12 Thread Django 
#25170: assertXMLEqual fails when white space is present outside XML fragment
---+
 Reporter:  shelldweller   |Owner:  quamilek
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  test   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.5856b6fbed11d5f02e25ce7f3e0fecb1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25267: Misleading error message for field in list_editable and not in list_display

2015-08-12 Thread Django 
#25267: Misleading error message for field in list_editable and not in 
list_display
--+
 Reporter:  michalwerner  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  admin, error message  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.ccb4ab9e9e0f29d6481bd207025639c1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25267: Misleading error message for field in list_editable and not in list_display

2015-08-12 Thread Django 
#25267: Misleading error message for field in list_editable and not in 
list_display
---+--
 Reporter:  michalwerner   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal |   Keywords:  admin, error message
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 Assume we have model with example filed {{{something}}}.
 Now, creating admin page, if we place {{{something}}} in
 {{{list_editable}}}, but NOT in `list_display` we have error like this:


 {{{
 SystemCheckError: System check identified some issues:

 ERRORS:
 : (admin.E122) The value of
 'list_editable[0]' refers to 'something', which is not an attribute of
 'someapp.SomeModel'.
 }}}

 Error message suggests that field {{{something}}} does not exist in model,
 but in fact it DOES exist in model and DOES NOT exist in admin's
 {{{list_display}}}, so the explanation is not true and leads to confusion.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.5fe73b1d9a87941e91f2d7cb50998a53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25172: System checks don't respect database routers

2015-08-12 Thread Django 
#25172: System checks don't respect database routers
-+-
 Reporter:  delinhabit   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  system-checks| Triage Stage:  Ready for
  multi-database |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by delinhabit):

 * needs_better_patch:  1 => 0
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.abf7edc906a9340d87d8798745038a2c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25261: Posts from feed not appearing in Django Community Blog

2015-08-12 Thread Django 
#25261: Posts from feed not appearing in Django Community Blog
---+-
 Reporter:  lferrari   |Owner:  timgraham
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:
 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 timgraham):

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


Comment:

 Fixed on our end by
 
https://github.com/django/djangoproject.com/commit/4894bea167497ef6992f12756b4e0679fff8bf95

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.32d915e32dafa0f1da22e3a228e59a91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25172: System checks don't respect database routers

2015-08-12 Thread Django 
#25172: System checks don't respect database routers
-+-
 Reporter:  delinhabit   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (System |  Version:  1.7
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  system-checks| Triage Stage:  Accepted
  multi-database |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.3176b3683c3a9fdfc361c49a33971cb3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25266: Allow regex for contrib.redirects

2015-08-12 Thread Django 
#25266: Allow regex for contrib.redirects
---+--
 Reporter:  berkerpeksag   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.redirects  |  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
---+--

Comment (by aaugustin):

 I had the same initial reaction to this ticket as Tim.

 In addition, this would change the interpretation of URLs containing a
 `.`, a `+`, or any other character that has a special meaning in regex. I
 don't have a good idea to preserve backwards compatibility there.

 There's also the question of how we would implement this efficiently. Not
 all supported databases can anwser "give me the list of rows where field
 `old_path` is a regex matching this value.

 I think a custom middleware (if you have many patterns) — perhaps a
 modified version of `RedirectFallbackMiddleware` — or a `RedirectView` (if
 you have a handful of patterns) is the way 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.0888ed29b807af32e4e0e43d9c4c4d35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25266: Allow regex for contrib.redirects

2015-08-12 Thread Django 
#25266: Allow regex for contrib.redirects
---+--
 Reporter:  berkerpeksag   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.redirects  |  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 timgraham):

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


Comment:

 I think writing regular expressions is better left to developers, in which
 I think using `RedirectView` or web server redirects should be sufficient.
 Feel free to write to the mailing list to get some other opinions.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.273382613fc33e219ffc62b7c0fa7fce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25254: Allow control over json.dumps keyword arguments in JsonResponse

2015-08-12 Thread Django 
#25254: Allow control over json.dumps keyword arguments in JsonResponse
-+-
 Reporter:  jaap3|Owner:  darkryder
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  json dumps indent| Triage Stage:  Ready for
  separators jsonresponse|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"d0bd5330432e1dda519ebd89606bd0980a36dcb4" d0bd533]:
 {{{
 #!CommitTicketReference repository=""
 revision="d0bd5330432e1dda519ebd89606bd0980a36dcb4"
 Fixed #25254 -- Added JsonResponse json_dumps_params parameter.
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.7e5822e416896d6f4ff1f7f32d80f3ae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25266: Allow regex for contrib.redirects

2015-08-12 Thread Django 
#25266: Allow regex for contrib.redirects
---+
 Reporter:  berkerpeksag   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.redirects  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 It would be really helpful if contrib.redirects would also accept a regex
 pattern as input.

 For example, in [https://github.com/python/pythondotorg/issues/462 some
 cases] we want to redirect `http://www.python.org/doc/X.Y.X/whatsnew/*` to
 `http://www.python.org/release/X.Y.X/whatsnew/*`.

 I can work on a patch if this seems reasonable.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.64925295f459a9d291e5118460a3906b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24257: The trans template tag fails to get a message when there is a % character in the string

2015-08-12 Thread Django 
#24257: The trans template tag fails to get a message when there is a % 
character
in the string
-+-
 Reporter:  aboudreault  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.7
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  trans templatetag| Triage Stage:  Accepted
  i18n   |
Has patch:  1|  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:"b7508896fbe19ec2cdeb81565cd587091b6b68d0" b7508896]:
 {{{
 #!CommitTicketReference repository=""
 revision="b7508896fbe19ec2cdeb81565cd587091b6b68d0"
 Fixed #24257 -- Corrected i18n handling of percent signs.

 Refactored tests to use a sample project.

 Updated extraction:
 * Removed special handling of single percent signs.
 * When extracting messages from template text, doubled all percent signs
   so they are not interpreted by gettext as string format flags. All
   strings extracted by gettext, if containing a percent sign, will now
   be labeled "#, python-format".

 Updated translation:
 * Used "%%" for "%" in template text before calling gettext.
 * Updated {% trans %} rendering to restore "%" from "%%".
 }}}

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.1b57ab9ea6fcb84911a177ac5bb89b5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25225: Unnecessary/Redundant __iter__ method with ListMixin class (contrib.gis.geos.mutable_list.py)?

2015-08-12 Thread Django 
#25225: Unnecessary/Redundant __iter__ method with ListMixin class
(contrib.gis.geos.mutable_list.py)?
-+-
 Reporter:  bixb0012 |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  __iter__ geos gis| Triage Stage:  Accepted
  ListMixin  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 [https://github.com/django/django/pull/5132 PR]

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7c977f5d765552fa10a39cd83a019287%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25264: Misleading list of options available for manage.py commands

2015-08-12 Thread Django 
#25264: Misleading list of options available for manage.py commands
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 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 timgraham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I don't know that this is a big problem that is worth changing, but I
 guess if someone wants to propose a patch to fix the issue for
 `runserver`, we could entertain it. The documentation says these options
 are "[https://docs.djangoproject.com/en/1.8/ref/django-admin/#default-
 options available on all options]" so this would require an update too.
 One consideration is that subclasses of `runserver` might use these
 options (`verbosity` most likely) so removing them by default would be
 backwards incompatible.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f5ac17cd730b38f3d507371e96119448%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25263: How closely we should adhere to PEP 257

2015-08-12 Thread Django 
#25263: How closely we should adhere to PEP 257
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 timgraham):

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


Comment:

 I agree with what has already been said.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.40636ee46c592c19b7ffed2bf839da94%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25265: DB Backend cannot specify query class.

2015-08-12 Thread Django 
#25265: DB Backend cannot specify query class.
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 jarshwah):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure what the solution to this problem is, but after discussing it
 at pycon with techdragon I agree that it'd be a nice thing to fix.

 Here's a couple of things off the top of my head:

 1) Meta option per model: Meta: query_backend =
 'django.db.models.sql.query'
 2) A DATABASES option
 3) A new queryset method
 `Model.objects.with('django.db.models.sql.query')`

 But I also think that we need to define the API between queryset and
 query, so that actually writing different query backends is realistic. Not
 a requirement for a solution here though.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.891587c0ef628502639363b16f40028e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25263: How closely we should adhere to PEP 257

2015-08-12 Thread Django 
#25263: How closely we should adhere to PEP 257
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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
-+-

Comment (by akaariai):

 I agree with claudep. The idea is that you have clean and well structured
 code so that it is easy to maintain. But there is a point after which the
 maintenance burden of all the rules is more than what we get in return. At
 this point I think we shouldn't add more rules, at least not without
 considering carefully if the new rules really give us enough in return.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a0a01d1b98077a46d21fd288448a0b95%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25265: DB Backend cannot specify query class.

2015-08-12 Thread Django 
#25265: DB Backend cannot specify query class.
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 akaariai):

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


Comment:

 The problem is that QuerySets aren't tied to any given backend. What
 should happen if you have two backends, one for mongodb and other for
 postgres, and the user does User.objects.filter(id=10).using('postgres')?
 Maybe this could be an error?

 I'm not sure what we could do to help nonsql backends. Some sort of
 User.objects.all() returns nonsql QuerySet seems like a possible addition,
 but I'm not sure what that mechanism should be.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.e6d4818c4fe193a195685d89715fa941%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25263: How closely we should adhere to PEP 257

2015-08-12 Thread Django 
#25263: How closely we should adhere to PEP 257
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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
-+-

Comment (by claudep):

 I think we have already many code quality checks with Flake8. Are those
 conventions really adding value or is this just a trend to adhere to more
 conventions? Frankly, the important thing for me is to have documentation.
 Then if we add newlines or not for single line comments and such things
 look more and more like bikeshedding for me. 

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.ee38076bec0fe80bed47f8d20793f190%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25265: DB Backend cannot specify query class.

2015-08-12 Thread Django 
#25265: DB Backend cannot specify query class.
--+
 Reporter:  techdragon|  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 It would be beneficial if the Queryset class
 (django.db.models.query.QuerySet) could use some mechanism to find out
 which query class the database backend wants to use.

 Without some mechanism to specify the query class, non sql based database
 backends are made drastically more complex.

 Adding something like "get_query" on the database backends that returns
 'sql.Query' in the existing backends would enable new backends to provide
 their own query class.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.11a86054653535c0eb5a8a95893f6506%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25264: Misleading list of options available for manage.py commands (was: Misleading)

2015-08-12 Thread Django 
#25264: Misleading list of options available for manage.py commands
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 mlorant):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.711ced78f55f4b7da6eba97dbe5a479d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25264: Misleading

2015-08-12 Thread Django 
#25264: Misleading
+
 Reporter:  mlorant |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Every commands has some options available, since the `BaseCommand`
 initialize some options to the options parser: verbosity, settings,
 traceback..

 However, this can be misleading, because these arguments are not used by
 every commands and sometimes this choice is ''by design''. For example,
 the `runserver` command does not use the `verbosity` option, and it has
 been explained why only there: https://code.djangoproject.com/ticket/15132

 I think the framework should not show generic options that are not used in
 the current commands (through an explicit list of generic options ignored
 or an explicit list of commands used ?)

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.7b65bbe01271a17cca2f84a1d9df7eb8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25263: How closely we should adhere to PEP 257

2015-08-12 Thread Django 
#25263: How closely we should adhere to PEP 257
-+-
 Reporter:  techdragon   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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 techdragon):

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


Old description:

> Currently the documentation contained in Django's source code has many
> places where it could be improved, most significantly by having more of
> it. In order to help discover undocumented code, I ran PEP 257 on the
> entire project. The thousands of warnings were quite a shock and it was
> pretty obvious that a pull request for all of the changes would be too
> large.
>
> It seemed like a good idea to open this ticket and find out if continuing
> to create new tickets and pull requests for more of this kind of
> documentation improvement is in line with the overall project code
> standards. I'm opening a pull request that contains a partial cleanup of
> the existing documentation inside 'django.views'.

New description:

 Currently the documentation contained in Django's source code has many
 places where it could be improved, most significantly by having more of
 it. In order to help discover undocumented code, I ran PEP 257 on the
 entire project. The thousands of warnings were quite a shock and it was
 pretty obvious that a pull request for all of the changes would be too
 large.

 It seemed like a good idea to open this ticket and find out if continuing
 to create new tickets and pull requests for more of this kind of
 documentation improvement is in line with the overall project code
 standards. I'm opening a pull request that contains a partial cleanup of
 the existing documentation inside 'django.views'.
 https://github.com/django/django/pull/5131

--

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.4289b0c29cd314708d8bc5fdec081118%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25263: How closely we should adhere to PEP 257

2015-08-12 Thread Django 
#25263: How closely we should adhere to PEP 257
--+
 Reporter:  techdragon|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently the documentation contained in Django's source code has many
 places where it could be improved, most significantly by having more of
 it. In order to help discover undocumented code, I ran PEP 257 on the
 entire project. The thousands of warnings were quite a shock and it was
 pretty obvious that a pull request for all of the changes would be too
 large.

 It seemed like a good idea to open this ticket and find out if continuing
 to create new tickets and pull requests for more of this kind of
 documentation improvement is in line with the overall project code
 standards. I'm opening a pull request that contains a partial cleanup of
 the existing documentation inside 'django.views'.

--
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.e1f1a62ad497c482e14996fd2b1cfa0e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

2015-08-12 Thread Django 
#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by scenting):

 * cc: scenting@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.58e4a34cb871f3dab15779f9be8088ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.