date:20140406

Re: [Django] #22394: Several built in Lookups should actually be Transforms

2014-04-06 Thread Django

Comment (by akaariai):

There is a way to have year lookup as a Transform, and also have
specialized Lookups for exact and friends. The way to do this is to write
YearExact's as_sql() in a way that it accesses directly self.lhs.lhs, that
is YearExact doesn't execute self.lhs.as_sql() at all, instead it skips
directly to the column of self.lhs. This works as self.lhs is known to be
a YearTransform instance, only way to access YearExact is through
YearTransform.

As it happens this has already been written as a test case in
custom_lookups. Check YearTransform and YearExact in
custom_lookups/tests.py. The implementation is PostgreSQL specific, so
there is some work to make it generic.

BTW for the kickstarter part - I think it is completely fair if somebody
else has time to work on this and implements it for you for your
kickstarter project. If you would be able to just merge patches others
wrote I think that would be completely fair way to accomplish your
kickstarter project. Of course, this is just my opinion.

--
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.343007b0f7286882df54a73e5aafa891%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20815: daemonize.py: unbuffered text IO error (python3)

2014-04-06 Thread Django

#20815: daemonize.py: unbuffered text IO error (python3)
--+
 Reporter:  alex01@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  python3 runfcgi open  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timo):

 Ticket for FastCGI deprecation is #20766.

-- 
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/074.24b1e2966f4dfd37e3c0019cbe5c6c6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

2014-04-06 Thread Django

Comment (by CollinAnderson):

It looks like testing against the latest version of pymysql, 0.6.1
(October 2013), there are some errors, but, using pymysql's master branch,
there are at least fewer errors. Some recent things that have been fixed
are Thing2Literal and query encoding. I also have a pull request in to fix
dates before 1900. It looks like there's a ticket open for timezone
support.

It seems to me we should try to fix pymysql as much as possible to try to
get it compatible with MySQLdb, and then require the latest version of
pymysql.

Also, I'm personally interested in also using pymysql on python2.7, so I
would prefer the fallback approach myself. Though, it's clear the real
benefit of this is for python 3.

--
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/072.7613ff3fa1014d1a6e99190d01db2fd7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22102: Wrong test ordering

2014-04-06 Thread Django

#22102: Wrong test ordering
-+-
 Reporter:  aptiko   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.6
 Severity:  Normal   |   Resolution:
 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 timo):

 * 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/064.d7a8d9ae3bc0a0cf868e7164cde2a5ae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22395: Deleting a model and fields that relate to it results in ValueError: Related model '.' cannot be resolved

2014-04-06 Thread Django

#22395: Deleting a model and fields that relate to it results in ValueError:
Related model '.' cannot be resolved
+
 Reporter:  melinath|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 This seems to happen because a single migration is created which both
 deletes the model and the fields that reference it - but the fields are
 (sometimes?) deleted second, so the model is already "gone" by the time
 the migration gets that far.

 Workaround is to move the field deletions up in the migrations file to
 *before* the model deletion.


 Generated migration (relevant bits):
 {{{
 [...]
 class Migration(migrations.Migration):

 operations = [

 migrations.DeleteModel(
 name='House',
 ),
 migrations.RemoveField(
 model_name='housingslot',
 name='house',
 ),
 migrations.RemoveField(
 model_name='person',
 name='house',
 ),
 ]

 }}}

 Traceback:

 {{{
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File ".../django/django/core/management/__init__.py", line 427, in
 execute_from_command_line
 utility.execute()
   File ".../django/django/core/management/__init__.py", line 419, in
 execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File ".../django/django/core/management/base.py", line 288, in
 run_from_argv
 self.execute(*args, **options.__dict__)
   File ".../django/django/core/management/base.py", line 337, in execute
 output = self.handle(*args, **options)
   File ".../django/django/core/management/commands/migrate.py", line 145,
 in handle
 executor.migrate(targets, plan, fake=options.get("fake", False))
   File ".../django/django/db/migrations/executor.py", line 60, in migrate
 self.apply_migration(migration, fake=fake)
   File ".../django/django/db/migrations/executor.py", line 94, in
 apply_migration
 migration.apply(project_state, schema_editor)
   File ".../django/django/db/migrations/migration.py", line 97, in apply
 operation.database_forwards(self.app_label, schema_editor,
 project_state, new_state)
   File ".../django/django/db/migrations/operations/fields.py", line 36, in
 database_forwards
 field,
   File ".../django/django/db/backends/sqlite3/schema.py", line 117, in
 add_field
 self._remake_table(model, create_fields=[field])
   File ".../django/django/db/backends/sqlite3/schema.py", line 84, in
 _remake_table
 self.create_model(temp_model)
   File ".../django/django/db/backends/schema.py", line 191, in
 create_model
 definition, extra_params = self.column_sql(model, field)
   File ".../django/django/db/backends/schema.py", line 108, in column_sql
 db_params = field.db_parameters(connection=self.connection)
   File ".../django/django/db/models/fields/related.py", line 1758, in
 db_parameters
 return {"type": self.db_type(connection), "check": []}
   File ".../django/django/db/models/fields/related.py", line 1749, in
 db_type
 rel_field = self.related_field
   File ".../django/django/db/models/fields/related.py", line 1655, in
 related_field
 return self.foreign_related_fields[0]
   File ".../django/django/db/models/fields/related.py", line 1414, in
 foreign_related_fields
 return tuple(rhs_field for lhs_field, rhs_field in
 self.related_fields)
   File ".../django/django/db/models/fields/related.py", line 1401, in
 related_fields
 self._related_fields = self.resolve_related_fields()
   File ".../django/django/db/models/fields/related.py", line 1386, in
 resolve_related_fields
 raise ValueError('Related model %r cannot be resolved' % self.rel.to)
 ValueError: Related model 'brambling.House' cannot be resolved
 }}}

-- 
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/051.6d8967cb8b583e3b56ec5519b149f5f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20815: daemonize.py: unbuffered text IO error (python3)

2014-04-06 Thread Django

#20815: daemonize.py: unbuffered text IO error (python3)
--+
 Reporter:  alex01@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  python3 runfcgi open  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by dk+django@…):

 Replying to [comment:1 claudep]:
 > Maybe someone more knowledgeable about buffered/unbuffered output may
 chime in to enlighten us?

 Change it to
  {{{open( out_log, 'a+', 1)}}}
 This buffers up to the next EOL, which makes sense for log files. (Same
 for {{{err_log}}})

 As per [https://docs.python.org/3/library/functions.html#open Python3
 docs]:
 > buffering is an optional integer used to set the buffering policy. Pass
 0 to switch buffering off (only allowed in binary mode), 1 to select line
 buffering (only usable in text mode)

 Looking at [https://docs.python.org/2/library/functions.html#open open()
 in Python2], line buffering should also work:
  - If something goes wrong while writing to {{{out_log}}}, you get an
 exception
  - I haven't yet seen {{{traceback}}} failing in the middle of a line, so
 it is probably also safe for {{{err_log}}}

 Hope this helps.

-- 
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/074.eb78cf31834a02190a18c22ee338fb67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] cd914e: Fixed #21977 -- Deprecated SimpleTestCase.urls

2014-04-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: cd914e31c9a889f18c50c15b4f6ee4959624001f
  
https://github.com/django/django/commit/cd914e31c9a889f18c50c15b4f6ee4959624001f
  Author: Anubhav Joshi 
  Date:   2014-04-06 (Sun, 06 Apr 2014)

  Changed paths:
M django/contrib/auth/tests/test_context_processors.py
M django/contrib/auth/tests/test_decorators.py
M django/contrib/auth/tests/test_remote_user.py
M django/contrib/auth/tests/test_signals.py
M django/contrib/auth/tests/test_templates.py
M django/contrib/auth/tests/test_views.py
M django/contrib/flatpages/tests/test_csrf.py
M django/contrib/flatpages/tests/test_middleware.py
M django/contrib/flatpages/tests/test_templatetags.py
M django/contrib/flatpages/tests/test_views.py
M django/contrib/formtools/tests/tests.py
M django/contrib/formtools/tests/wizard/namedwizardtests/tests.py
M django/contrib/formtools/tests/wizard/wizardtests/tests.py
M django/contrib/gis/tests/geoadmin/tests.py
M django/contrib/gis/tests/geoapp/test_feeds.py
M django/contrib/gis/tests/geoapp/test_sitemaps.py
M django/contrib/messages/tests/base.py
M django/contrib/messages/tests/test_mixins.py
M django/contrib/sitemaps/tests/base.py
M django/contrib/sitemaps/tests/test_https.py
M django/test/testcases.py
M docs/internals/deprecation.txt
M docs/releases/1.8.txt
M docs/topics/testing/tools.txt
M tests/admin_changelist/tests.py
M tests/admin_custom_urls/tests.py
M tests/admin_docs/tests.py
M tests/admin_inlines/tests.py
M tests/admin_scripts/tests.py
M tests/admin_views/tests.py
M tests/admin_widgets/tests.py
M tests/cache/tests.py
M tests/conditional_processing/tests.py
M tests/contenttypes_tests/tests.py
M tests/context_processors/tests.py
M tests/deprecation/tests.py
M tests/file_storage/tests.py
M tests/file_uploads/tests.py
M tests/forms_tests/tests/test_widgets.py
M tests/generic_inline_admin/tests.py
M tests/generic_views/test_base.py
M tests/generic_views/test_dates.py
M tests/generic_views/test_detail.py
M tests/generic_views/test_edit.py
M tests/generic_views/test_list.py
M tests/handlers/tests.py
M tests/i18n/patterns/tests.py
M tests/i18n/tests.py
M tests/logging_tests/tests.py
M tests/middleware/tests.py
M tests/middleware_exceptions/tests.py
M tests/model_permalink/tests.py
M tests/proxy_models/tests.py
M tests/resolve_url/tests.py
M tests/servers/tests.py
M tests/staticfiles_tests/tests.py
M tests/syndication_tests/tests.py
M tests/template_tests/test_response.py
M tests/template_tests/tests.py
M tests/test_client/tests.py
M tests/test_client_regress/tests.py
M tests/test_utils/tests.py
M tests/timezones/tests.py
M tests/urlpatterns_reverse/tests.py
M tests/view_tests/tests/test_csrf.py
M tests/view_tests/tests/test_debug.py
M tests/view_tests/tests/test_defaults.py
M tests/view_tests/tests/test_i18n.py
M tests/view_tests/tests/test_json.py
M tests/view_tests/tests/test_shortcuts.py
M tests/view_tests/tests/test_specials.py
M tests/view_tests/tests/test_static.py
M tests/wsgi/tests.py

  Log Message:
  ---
  Fixed #21977 -- Deprecated SimpleTestCase.urls


-- 
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/5341c860d4df9_1a3dd73d4074413%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21977: Deprecate SimpleTestCase.urls in favor of override_settings

2014-04-06 Thread Django

#21977: Deprecate SimpleTestCase.urls in favor of override_settings
-+-
 Reporter:  timo |Owner:
 Type:   |  anubhav9042
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"cd914e31c9a889f18c50c15b4f6ee4959624001f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cd914e31c9a889f18c50c15b4f6ee4959624001f"
 Fixed #21977 -- Deprecated SimpleTestCase.urls
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/062.045e8df193fc7686137d09ffcadc897f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20815: daemonize.py: unbuffered text IO error (python3)

2014-04-06 Thread Django

#20815: daemonize.py: unbuffered text IO error (python3)
--+
 Reporter:  alex01@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  python3 runfcgi open  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by dk+django@…):

 Replying to [comment:2 aaugustin]:
 > Note that FastCGI is deprecated in 1.7.

 Interesting decision, why so? Cannot spot any rationale in the 1.7 release
 notes. Pointers?
 However, the error is not really fcgi-related, any code using
 django/utils/daemonize.py will have the same issue in Py3k.
 Log files are text files, and you cannot open them in unbuffered mode.

-- 
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/074.a8fe171dd834aafd06e3a56a3d0f295f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

2014-04-06 Thread Django

#22383: Add the required tag to the input fields which are required for database
entry
-+---
 Reporter:  abhishek.garg@…  |Owner:  anubhav9042
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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 anubhav9042):

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


-- 
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/084.26a8d2b05fca8b8799b48ff067587a13%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22394: Several built in Lookups should actually be Transforms

2014-04-06 Thread Django

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

Comment:

Doing something with this issue is part of my kickstarter, so it would
probably be unfair for someone else to work on it.

I believe the current machinery is enough to provide "optimal" queries in
all circumstances. This will work by making `__year` a `Transform` which
is actually a no-op, and that transform having a set of lookups available
to it distinct from the normal lookups, which each both extract the year
*and* do the comparison. This allows us to use `EXTRACT` for the exact
case but not for the less than case (for example). (Note that if `__year`
becomes a transform all calls to `__year` explicitly become
`__year__exact`). At present, lookups and only used in filter queries. We
will need to be more intelligent here when considering their use in values
calls, custom index etc as then a `__year` transform cannot be a noop.

To work out the best option for each possible call here, I will be running
benchmarks and checking query plans, with and without indexes, for all the
possible queries. We can then work out what the best query is for each db
in each case - they need not necessarily be the same.

It is also possible with custom indexes that there may be a case for the
`__year` transform having a `__extract` transform which forces the use of
`EXTRACT()` at SQL level. This would be an unusual use case for year, but
perhaps more likely for `__date` or `__week` where a user could add an
index for this particular extract and then perform efficient queries using
it without needing to index the entire table. This could be much more
efficient with logging-like tables, but until I try it out I don't know.

--
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.d8461224ad91010a357852c33fd06d26%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

2014-04-06 Thread Django

#22391: fallback to pymysql if MySQLdb not available
-+-
 Reporter:  CollinAnderson   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 I have also a dedicated branch for this:
 https://github.com/claudep/django/tree/pymysql. However, I think the test
 suite does not entirely pass with that patch.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/072.9bb13d0e7380483cedf167d6ec6c7123%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

2014-04-06 Thread Django

#22383: Add the required tag to the input fields which are required for database
entry
-+
 Reporter:  abhishek.garg@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  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 anubhav9042):

 Ok.
 Wouldn't it be better to provide people to choose whether they want to go
 the conventional way or other just like in case of `required_css_class`

 But also as Tim Graham says "I don't think the feature will be used very
 much if it isn't turned on by default." also seems valid situation.

 Thoughts?

-- 
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/084.1eb064a5122804e4b7332ee6d75f79c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

2014-04-06 Thread Django

Comment (by timo):

A form attribute doesn't seem like the most elegant solution, but it's
consistent with other form attributes like `Form.required_css_class` and I
cannot think of a better way. A setting is obviously a no-go...

I suggest calling it `use_required_attribute` instead of
`required_html_tag`. IMO, I think most people would want this behavior so
the attribute could default to `True` and people could opt-out by setting
it to `False`. It would just need to be noted in the release notes as a
backwards incompatible change.

--
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/084.c50b6cb47db1c93610b7d8181cdbf8c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

2014-04-06 Thread Django

#22383: Add the required tag to the input fields which are required for database
entry
-+
 Reporter:  abhishek.garg@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  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 anubhav9042):

 I did some work here:
 https://github.com/coder9042/django/compare/ticket_22383?expand=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/084.d71f5b4741ba31a9138a41f874f4c0f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13147: auth.UserCreationForm : unicity check on username not necessary

2014-04-06 Thread Django

#13147: auth.UserCreationForm : unicity check on username not necessary
-+-
 Reporter:  peyman   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.1
Component:  contrib.auth |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by flisky):

 A real fix comes from https://github.com/django/django/pull/2521 with some
 cleanup.

-- 
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/064.15f55af5f34b09679025a7dda16b6a1e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11154: Inconsistency with permissions for proxy models

2014-04-06 Thread Django

#11154: Inconsistency with permissions for proxy models
-+-
 Reporter:  etianen  |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  proxy contenttype| Triage Stage:  Accepted
  permission |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Using 1.6 and can confirm this is still an issue.  Any idea what's the
 latest on this?  Thanks,

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.b2a61dc5ca97904a16615435b076a8a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

2014-04-06 Thread Django

#22383: Add the required tag to the input fields which are required for database
entry
-+
 Reporter:  abhishek.garg@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  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 anubhav9042):

 Loic suggested that this would be good as an optional feature.

-- 
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/084.2ea1f11be2e349945d06778c68487b81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22310: Document exact usage of and consequences of rotating SECRET_KEY

2014-04-06 Thread Django

#22310: Document exact usage of and consequences of rotating SECRET_KEY
--+
 Reporter:  erikr |Owner:  Zulu
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+

Comment (by erikr):

 I think https://docs.djangoproject.com/en/dev/topics/signing/ might be the
 best place, as that's what SECRET_KEY is already described as being used
 for from the settings documentation.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.3d42099f5eee5b77e91fab4cd61d7602%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22310: Document exact usage of and consequences of rotating SECRET_KEY

2014-04-06 Thread Django

#22310: Document exact usage of and consequences of rotating SECRET_KEY
--+
 Reporter:  erikr |Owner:  Zulu
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+

Comment (by Zulu):

 Where does this doc should be included ?

-- 
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.9b6f5880814294c9c3c72dd81c636604%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22310: Document exact usage of and consequences of rotating SECRET_KEY

2014-04-06 Thread Django

#22310: Document exact usage of and consequences of rotating SECRET_KEY
--+
 Reporter:  erikr |Owner:  Zulu
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+
Changes (by Zulu):

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


-- 
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.0d05c9718bf31a7ebff1f35e12777906%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22394: Several built in Lookups should actually be Transforms

2014-04-06 Thread Django

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

Comment:

Discussion on IRC mentions that the `Year` lookup does a range query
(BETWEEN x AND y) which is able to use date based indexes. If a Transform
were to be used, any field based indexes would be invalid, as a computed
/function-based index would need to be created instead to preserve
performance.

However, all other operations based on date fields do an EXTRACT(), which
can't use traditional indexes anyway. Having Year as a Lookup but the
other date/time lookups as Transforms doesn't really make sense either,
and would probably be more confusing than it is now.

--
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.0deb2945ae702f4140131c8167b6c2ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22394: Several built in Lookups should actually be Transforms

2014-04-06 Thread Django

#22394: Several built in Lookups should actually be Transforms
--+-
 Reporter:  smeatonj  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  lookups
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 The following built in lookups should be Transforms rather than Lookups,
 because we're transforming the date/time into a date/time part:

 `Year, Month, Day, WeekDay, Hour, Minute, Second.`

 Converting the above into Transforms then allows a Lookup to proceed:

 `qs.filter(date_field__year__gte=2001)`

-- 
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/051.b1f085f73f9423d58ada448645e238f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

2014-04-06 Thread Django

#22391: fallback to pymysql if MySQLdb not available
-+-
 Reporter:  CollinAnderson   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Related: #12500.

-- 
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/072.ed04f007e78e7edb02ee523c1ae01c4b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

2014-04-06 Thread Django

#22391: fallback to pymysql if MySQLdb not available
-+-
 Reporter:  CollinAnderson   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by loic84):

 * stage:  Unreviewed => Accepted


Comment:

 I agree it'd be nice to have support for pymysql, and I actually worked on
 it a little while ago before giving up.

 I don't think a fallback mechanism is the right approach though, I'd much
 prefer a minimal yet separate db backend that'd leverage most of the
 implementation of the default backend.

 Did you manage to get the test suite to work with this patch? I remember
 running into a lot of issues when I tried.

-- 
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/072.289e68b13be85383b9319cfd9176ade8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22394: Several built in Lookups should actually be Transforms

Re: [Django] #20815: daemonize.py: unbuffered text IO error (python3)

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

Re: [Django] #22102: Wrong test ordering

[Django] #22395: Deleting a model and fields that relate to it results in ValueError: Related model '.' cannot be resolved

Re: [Django] #20815: daemonize.py: unbuffered text IO error (python3)

[django/django] cd914e: Fixed #21977 -- Deprecated SimpleTestCase.urls

Re: [Django] #21977: Deprecate SimpleTestCase.urls in favor of override_settings

Re: [Django] #20815: daemonize.py: unbuffered text IO error (python3)

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

Re: [Django] #22394: Several built in Lookups should actually be Transforms

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

Re: [Django] #13147: auth.UserCreationForm : unicity check on username not necessary

Re: [Django] #11154: Inconsistency with permissions for proxy models

Re: [Django] #22383: Add the required tag to the input fields which are required for database entry

Re: [Django] #22310: Document exact usage of and consequences of rotating SECRET_KEY

Re: [Django] #22310: Document exact usage of and consequences of rotating SECRET_KEY

Re: [Django] #22310: Document exact usage of and consequences of rotating SECRET_KEY

Re: [Django] #22394: Several built in Lookups should actually be Transforms

[Django] #22394: Several built in Lookups should actually be Transforms

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

Re: [Django] #22391: fallback to pymysql if MySQLdb not available

25 matches

Site Navigation

Mail list logo

Footer information