Re: Order of INSTALLED_APPS

[Kevin Christopher Henry]

Sorry to be late to this thread, I just came across it.

There's another place where the order of INSTALLED_APPS matters: management 
commands. Management commands associated with apps that come later in 
INSTALLED_APPS will replace those with the same name that are listed 
earlier. I can't find this documented anywhere, but a look at the code 
confirms it. South, for example, takes advantage of this to override the 
syncdb command (and hints at the ordering issue when the documentation 
says: "add 'south' to the end of INSTALLED_APPS").

So a documentation update should probably note this specifically in the 
management documentation, as well as mentioning it in the box for 
INSTALLED_APPS. (I also think static files should also be mentioned in the 
box, since as Aymeric points out that is another area dependent on the 
order of apps.)

One thing that's unfortunate is that the semantics of ordering for 
management commands is opposite that of the other cases. For templates, 
static files, and translations, listing an app *first *gives it precedence, 
whereas with management commands it's listing it *last.* Ideally this would 
be changed so that management commands were consistent with the other 
cases, but that would create serious backwards compatibility issues. Like, 
breaking everyone's South installation. :-O

Cheers,
Kevin


On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>
> Done! https://code.djangoproject.com/ticket/20914#ticket
>
> thanks!
>
> On Tuesday, August 13, 2013 12:20:48 PM UTC+2, Aymeric Augustin wrote:
>>
>> 2013/8/13 Stefano Crosta 
>>
>>> My proposal would then be to simply add another box to the 
>>> https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps to 
>>> say "order matters" once more and link the other two pages for translations 
>>> and templates.
>>> *if you think this would* help I could do it as well as a ticket. To 
>>> save everybody's time no answer will mean it's not worth it!
>>>
>>
>> Yes, please file one, and include a link to this discussion.
>>
>> -- 
>> Aymeric. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Order of INSTALLED_APPS

[Kevin Christopher Henry]

You're right, it would only matter if multiple apps (not core) were trying 
to use the same command. Which presumably doesn't happen very often?

I filed a ticket here: https://code.djangoproject.com/ticket/21018.


On Sunday, September 1, 2013 6:04:03 PM UTC-4, Marc Tamlyn wrote:
>
> I don't think it would break South installations as custom app commands 
> will always override builtins. Could you open a ticket for that? The 
> inconsistency is problematic. Obviously it would be backwards incompatible, 
> but we need to gauge the size of the impact.
>
> Marc
> On 1 Sep 2013 21:31, "Kevin Christopher Henry" 
> <k...@severian.com> 
> wrote:
>
>> Sorry to be late to this thread, I just came across it.
>>
>> There's another place where the order of INSTALLED_APPS matters: 
>> management commands. Management commands associated with apps that come 
>> later in INSTALLED_APPS will replace those with the same name that are 
>> listed earlier. I can't find this documented anywhere, but a look at the 
>> code confirms it. South, for example, takes advantage of this to override 
>> the syncdb command (and hints at the ordering issue when the documentation 
>> says: "add 'south' to the end of INSTALLED_APPS").
>>
>> So a documentation update should probably note this specifically in the 
>> management documentation, as well as mentioning it in the box for 
>> INSTALLED_APPS. (I also think static files should also be mentioned in the 
>> box, since as Aymeric points out that is another area dependent on the 
>> order of apps.)
>>
>> One thing that's unfortunate is that the semantics of ordering for 
>> management commands is opposite that of the other cases. For templates, 
>> static files, and translations, listing an app *first *gives it 
>> precedence, whereas with management commands it's listing it *last.*Ideally 
>> this would be changed so that management commands were consistent 
>> with the other cases, but that would create serious backwards compatibility 
>> issues. Like, breaking everyone's South installation. :-O
>>
>> Cheers,
>> Kevin
>>
>>
>> On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>>>
>>> Done! 
>>> https://code.**djangoproject.com/ticket/**20914#ticket<https://code.djangoproject.com/ticket/20914#ticket>
>>>
>>> thanks!
>>>
>>> On Tuesday, August 13, 2013 12:20:48 PM UTC+2, Aymeric Augustin wrote:
>>>>
>>>> 2013/8/13 Stefano Crosta <stefano...@gmail.com>
>>>>
>>>>> My proposal would then be to simply add another box to the 
>>>>> https://docs.**djangoproject.com/en/dev/ref/**settings/#installed-apps<https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps>
>>>>>  to 
>>>>> say "order matters" once more and link the other two pages for 
>>>>> translations 
>>>>> and templates.
>>>>> *if you think this would* help I could do it as well as a ticket. To 
>>>>> save everybody's time no answer will mean it's not worth it!
>>>>>
>>>>
>>>> Yes, please file one, and include a link to this discussion.
>>>>
>>>> -- 
>>>> Aymeric. 
>>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Kevin Christopher Henry]

>
>
> We probably cannot move checks of `primary_key` and `unique` living in
> `FileField.__init__`. We test if one of these two parameters was passed; we
> don't check their values. Consider that an user passes unique=False. This 
> is
> the default value, but nevertheless, this should result in an error. We
> cannot check if the attributes where passed while performing system 
> checks. I'm
> not sure if I make myself clear.
>
>
Why not just store a reference to the original arguments (or the relevant 
subsets) in __init__(), and then validate them later in a system check? 
That may seem a little indirect, but I think the validation system will be 
much nicer if we can do everything in system checks instead of splitting 
the work with __init__().

I think there are other places as well where we'd like to do this kind of 
check. For example, right now you can create a OneToOneField with 
unique=False and Django will silently overwrite that value and your model 
will validate just fine. It would be much better if trying to specify 
unique on a OneToOneField caused a validation error, and the same sort of 
pattern could be applied there: storing a reference to the original value 
during __init__(), overwriting with unique=True for the purposes of 
initializing the parent ForeignKey, and then checking the user-supplied 
value in a separate system check. (This is just an example, I'm not saying 
that you should make this change to OneToOneField now, as it's 
backwards-incompatible.)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revert 165f44aa?

[Kevin Christopher Henry]

To summarize the possible approaches here:

1) Combine multiple with statements into one wherever possible. This seems 
to be the approach of the commit in question.
2) Group with statements based on whether they logically belong together, 
regardless of line length. This will involve backslashes, but note that PEP 
8 specifically blesses this use case: "Long, multiple with-statements 
cannot use implicit continuation, so backslashes are acceptable".
3) Group together logically related with statements unless that would 
involve backslashes, in which case use separate with statements. I think 
this is Marc and Florian's suggestion. The problem here is that the 
grouping of with statements depends on both logical and lexical 
considerations, which seems somewhat less readable to me.
4) Revert the commit and stick with one with statement per line.

Personally, I prefer 4 or 2.

Kevin


On Saturday, September 21, 2013 5:16:04 PM UTC-4, Florian Apolloner wrote:
>
>
>
> On Saturday, September 21, 2013 7:50:34 PM UTC+2, Aymeric Augustin wrote:
>>
>> But whenever the with statement spills over two lines, which happens in a 
>> majority of cases, I find it worse than two with statements. It's 
>> especially bad in the transactions tests — I worked in this area today. 
>>
>
> Agreed; as a groundrule I'd say:
>  * If you need backslashes keep them separate
>  * If one is a test assertion keep them separate
>
> You have a point about consistency, but as long as they are readable I can 
> live with having to versions…
>
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

TestCase can produce surprising failures

[Kevin Christopher Henry]

I recently upgraded one of my projects to 1.6 and was surprised to find 
that some of my tests were failing.  I filed a ticket [1], and the 
subsequent discussion with Aymeric makes me think that there is a tricky 
issue here, worth discussing.

The basic problem is that when using TestCase you can end up with test 
failures for correct, non-transactional code, due to the fact that TestCase 
is wrapping your test in a transaction. Some examples:

- If your non-transactional code catches a database error and continues 
(which is perfectly fine), your TestCase test for it will produce a 
TransactionManagementError.
- Similarly, if your TestCase does an assertRaises() for a DatabaseError, 
and then hits the database again after that, you will get an error.
- Aymeric mentions: "The problem is not limited to database errors, it is 
known to happen if a post-save signal handler raises an exception."

The straightforward solution is to use TransactionTestCase instead. 
Currently, though, the documentation just advises you to use 
TransactionTestCase "when testing transactional behavior". These examples 
show that that advice is too limited. We should catalog the ways in which 
TestCase behavior can diverge from TransactionTestCase and update the 
documentation accordingly.

More broadly, though, this makes me wonder whether it's a good idea for the 
documentation to present TestCase as the de facto default base class for 
tests. On the one hand we have that old standby, TransactionTestCase 
(formerly known as TestCase), which slowly but safely plows through its 
tests, dutifully truncating tables. On the other hand we have TestCase, its 
younger usurper, which is much faster but which is also less general, 
failing in ways that could confuse new users who may not know anything 
about transaction management (and who are probably also the least likely to 
need the faster tests). Are we leading them into a premature optimization?

Cheers,
Kevin

[1] https://code.djangoproject.com/ticket/21540

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5471ca9a-fa4f-4c88-88b7-cbd9577d215f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Renaming apps.has_app

[Kevin Christopher Henry]

+1 for "is_installed"

I don't find the grammar objectionable here, just think of it as "is_(each 
one of these apps)_installed"


On Sunday, January 5, 2014 3:50:45 PM UTC-6, Aymeric Augustin wrote:
>
> On 5 janv. 2014, at 22:38, Raffaele Salmaso 
>  
> wrote: 
>
> > Should it takes a list of apps, just to replace 
> > apps.is_installed('djagno.contrib.sites') and 
> > apps.is_installed('django.contrib.admin') and ... 
> > with 
> > apps.is_installed('django.contrib.sites', 'django.contrib.admin',...) 
> > ? 
>
> That’s an interesting suggestion. But I don’t think it’s compatible with 
> the singular “is_installed”. It could work with just “installed”, though. 
>
> -- 
> Aymeric. 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8afb0a25-0482-46a6-87fb-7bca34af2366%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Kevin Christopher Henry]

Russell makes the very good point that Jinja2 isn't just a faster version 
of the Django template engine - it's philosophically at odds with the 
original design and intent of the Django template engine.

Personally, I prefer Jinja2's approach and would love to see it become the 
standard. (The benefits of improved performance, and of moving templates 
out of core, are nice as well.) But before there's a switch we would need 
to discuss this philosophical difference and come to a consensus that the 
Jinja2 approach is, at least, acceptable.

In the absence of a plan to eventually switch to Jinja2, I'm not sure a 
re-architecting (option 2) is a great use of time. Why? Because in my 
experience the existing solutions work fine. I'm using Jinja2 and the 
django-jinja adapter in my projects and everything pretty much just works.

As Russell pointed out, the one thing that doesn't just work is trying to 
use custom template tags. I haven't looked into this problem at all, but 
presumably it's a hard one since to my knowledge none of the Jinja2 
adapters allow you to do this. I think that the single best way to smooth 
adoption of Jinja2 would be to figure out a way for a Jinja2 template to 
use arbitrary Django template tags. 


On Saturday, February 8, 2014 7:56:17 PM UTC-5, Curtis Maloney wrote:
>
> Can I suggest a 3) to this?
>
> After getting involved with the internals of the template engine recently, 
> I came to the suspicion that a lot of the speed issues come from highly 
> defensive coding.
>
> Now, this is generally to be expected when safety is more important than 
> speed, but I am moderately firm of the opinion that some careful analysis 
> of the template code could help reveal places where the same guard [such as 
> mark_safe, force_text, etc] is being applied repeatedly but could be 
> avoided.
>
> So my (3) to this is to analyse the template code paths sufficiently to be 
> able to identify places where these guards can be omitted safely.
>
> --
> Curtis
>
>
>
> On 9 February 2014 11:11, Russell Keith-Magee 
>  > wrote:
>
>>
>> On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela 
>> > > wrote:
>>
>>> Hello! GSoC 2014 is coming and I'm thinking about issue to work on.
>>>
>>> The template system is one of the components that are of special 
>>> interest to me.
>>> One of the major issues is that rendering templates is slow. The problem 
>>> could
>>> be solved by compiling template to Python bytecode, but it seems to be 
>>> really
>>> hard to achieve, given that there was an unsuccessful attempt.
>>>
>>
>> This should set off a red flag for you. The GSoC project to byte code 
>> compile Django's templates was implemented by Armin, the same person who 
>> wrote Jinja2 - and yet the project didn't fully succeed. It's worth 
>> investigating *why* this idea failed, because it flags one of the reasons 
>> why "just adopt Jinja2" may not be a viable options.
>>   
>>
>>> Why not switching to Jinja2? I thought that somebody else proposed this 
>>> idea
>>> but I couldn't find any discussion; so, please, point me to the 
>>> discussion if
>>> the idea was discussed, otherwise let's discuss it!
>>>
>>
>> It's been proposed in jest, and it's been accepted in jest as well :-) 
>> However, I don't think there's been a serious proposal to this effect.
>>   
>>
>>> The pros are obvious: 1) fast templates, 2) less code to maintain, 3) 
>>> lot's of
>>> companies use Jinja2 (because of slowness of default template system) and
>>> builtin support for Jinja2 would be beneficial for them (thing about
>>> integrating Jinja2 with settings like TEMPLATE_DEBUG).
>>>
>>> Now the cons. First of all, one of the design decision is that Django 
>>> has no
>>> dependencies. We can overwhelm it by "static linking" -- I mean copying 
>>> Jinja2
>>> code into Django. At the first glance, it may look like a horrible idea, 
>>> but
>>> think about it in a different way. If we don't switch to Jinja2, we have 
>>> to
>>> maintain entire template system and fix every bug as well as implement 
>>> new
>>> features. If we switch, Jinja2 developers can do this job for us. We 
>>> only need
>>> to forward tickets to Jinja2 developers and update the static linkage.
>>>
>>
>> We're unlikely to vendor a copy of Jinja2. If we went down this road, 
>> we'd be much more likely to look at using dependencies defined in setup.py.
>>   
>>
>>> The second big problem is that switching is a big change and backward
>>> compatibility matters. We will need to support both the deprecated Django
>>> template system and the new one. However, it doesn't mean double work -- 
>>> we
>>> don't need to implement new features for the deprecated system, only bug 
>>> fixes
>>> will be required. Also note, that a lot of companies uses Jinja2 and 
>>> switching
>>> from third-package Jinja2 to Jinja2-builtin-Django isn't an enormous 
>>> change at
>>> all.
>>>
>>
>> Untrue. It *can* be a *very* big change. One 

Re: [GSoC] Switching to Jinja2 proposal

[Kevin Christopher Henry]

Hi Christopher,
 

>  ... checks the template extension and dispatch to
>  corresponding function from `django.dtl` or `jinja2`.
>

The mechanism for distinguishing the two kinds of template needs to be more 
flexible. For example, let's say I want to override a third-party template 
with my own Jinja template. In that case I need to use the same name (.html 
and all), but I want it to be processed by Jinja. The way django-jinja 
solves this is with a setting that provides a regular expression to 
determine which template names get processed by Jinja. That may not be the 
best way (I can imagine that regular expression getting hairy with a lot of 
"or" clauses), but just looking at file extensions isn't enough.

I don't have a comment on the merits of your approach to inheriting from 
DTL templates, but personally this is not something I've ever needed to do. 
I'm sure there are use cases for this, that's just my experience.

By contrast, something that I very often want to do is use third-party 
Django template tags in my Jinja2 templates. Right now there's just no way 
to do that (that I know of). So, if you're taking requests, please solve 
that problem. :-) And if you're forced to prioritize, I think that would be 
more useful than being able to inherit from DTL templates.

Cheers,
Kevin

 

>
>  - It would be nice to use the same loaders for both django.dtl and 
> jinja2. This
>requires to rewrite existing Django loaders so that they fulfill the 
> contract
>of `jinja2.Loader`. 
>
> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
>>> include/inherit DTL template from Jinja2 one and vice versa).
>>
>>
>> Including doesn't sound like it would be any problem, but inheriting? Is 
>> that really going to be possible?
>
>
> It seems to be possible. Consider parent Jinja2 template:
>
> Parent
> {% block overridden %}parent overridden block{% endblock %}
> {% block nonoverridden %}parent nonoverridden block{% endblock %}
>
> as well as child Jinja2 template:
>
> {% extends "parent.jinja2" %}
> {% block overridden %}child overridden block{% endblock %}
>
> Jinja2 compiles templates by generating valid Python code and passing it to
> `exec` function. The appropriate code for the former is:
>
> from __future__ import division
> from jinja2.runtime import LoopContext, TemplateReference, Macro, 
> Markup, TemplateRuntimeError, missing, concat, escape, markup_join, 
> unicode_join, to_string, identity, TemplateNotFound
> name = 'parent'
>
> def root(context, environment=environment):
> if 0: yield None
> yield u'Parent '
> for event in context.blocks['overridden'][0](context):
> yield event
> for event in context.blocks['nonoverridden'][0](context):
> yield event
>
> def block_nonoverridden(context, environment=environment):
> if 0: yield None
> yield u'parent nonoverridden block'
>
> def block_overridden(context, environment=environment):
> if 0: yield None
> yield u'parent overridden block'
>
> blocks = {'nonoverridden': block_nonoverridden, 'overridden': 
> block_overridden}
> debug_info = '1=8'
>
> and for the child is:
>
> from __future__ import division
> from jinja2.runtime import LoopContext, TemplateReference, Macro, 
> Markup, TemplateRuntimeError, missing, concat, escape, markup_join, 
> unicode_join, to_string, identity, TemplateNotFound
> name = 'child'
>
> def root(context, environment=environment):
> parent_template = None
> if 0: yield None
> parent_template = environment.get_template('parent.jinja2', 
> 'child')
> for name, parent_block in parent_template.blocks.iteritems():
> context.blocks.setdefault(name, []).append(parent_block)
> for event in parent_template.root_render_func(context):
> yield event
>
> def block_overridden(context, environment=environment):
> if 0: yield None
> yield u'child overridden block'
>
> blocks = {'overridden': block_overridden}
> debug_info = '1=8'
>
> As you can see, child template loads parent template using
> `environment.get_template` method; then iterates over its blocks; finally
> delegates to it by calling `root_render_func` and passing the context.
>
> We can write Jinja2 loader that checks the template extension; if it's 
> "jinja2",
> it delegates to another loader that is responsible for loading Jinja2 
> templates;
> otherwise, it loads appropriate Django template and wraps it with an 
> adapter.
> The adapter must have the same interface as `jinja2.Template` -- probably 
> only
> `blocks` and `root_render_func` need to be implemented. `root_render_func` 
> will
> be similar to `Template.render` and `blocks` is a map from block names to
> functions rendering these blocks (these functions will be similar to
> `BlockNode.render`). We also need to tamper with `BlockNode.render` 

Re: [GSoC] Switching to Jinja2 proposal

[Kevin Christopher Henry]

>
> What kind of support do you except for third-party template tags? Suppose, 
> that
> `cycle` tag is not builtin. Would it be acceptable to write sth like that:
>
> dtl cycle '1' '2' as rows
>
> It could be quite easily implemented as a Jinja2 extensions. Of course, I 
> guess
> that you'd prefer this style:
>
> cycle '1' '2' as rows
>

Good question. In my opinion, making the tag invocation look the same as it 
does in DTL should not be an important goal. These are different languages, 
after all, with different syntaxes and different calling conventions. For 
example, many things that need to be tags in DTL are just functions in 
Jinja. (django-jinja took this approach by implementing the built-in 'url' 
as a function rather than a tag.)

Another relevant issue is that there could be name ambiguities. In DTL you 
specify a module with the load tag, which allows you to have multiple apps 
that use the same template tag name. Without the load tag you need some way 
to specify which 'cycle' you're referring to. (This is not just an issue 
with wrapping DTL tags, it's also going to be an issue if multiple apps try 
to register global Jinja functions with the same name.)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57769035-c8c3-45a0-a7c3-4fc757b79497%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Unneeded index created with unique=True and db_index=False in TextField

[Kevin Christopher Henry]

This issue was the subject of https://code.djangoproject.com/ticket/24082.

There, the accepted (but not implemented) solution is the same as suggested 
here: allowing the user to opt out of the creation of the additional index 
with `db_index=False`.

On Wednesday, April 15, 2015 at 2:11:25 PM UTC-4, Some Developer wrote:
>
> On 15/04/15 18:22, Tim Graham wrote: 
> > #19441 is the ticket where it was decided that unique=True implies a 
> > database index. The documentation says, 
> > 
> > "Note that when ``unique`` is ``True``, you don't need to specify 
> > 
> > `Field.db_index`, because ``unique`` implies the creation of an index." 
> > 
>
> Understood. I just want to be able to stop the creation of the index in 
> some way. Whether that be via db_index=False or some other new method. 
>
> I would have thought that the creation of the index would be optional. I 
> understand that the default it to create the index and that is fine for 
> the vast majority of cases (in fact until I hit this little problem I 
> didn't care one way or another) but a user should have the option to 
> tell Django not to create the index if they are sure they know what they 
> are doing. 
>
> > Unless we decide that is wrong, I think the correct condition to solve 
> > the issue would be more like `field.db_index orfield.unique and 
> > field.db_index is not False`. We might also have to change the default 
> > keyword of Field from False to None so we know the difference between 
> > "unspecified" and False. 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7e481c16-ec13-4454-88b7-369c725ac30f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GitHub Issues for DEP repository?

[Kevin Christopher Henry]

Hello,

With all the talk of DEPs flying around I thought I'd finally take a look 
at one in detail.

I wanted to make a suggestion about it and realized that there wasn't 
really a good place to do so. The issue was too minor for a mailing list 
discussion, and there was no open pull request to comment on. My first 
instinct was to file a GitHub issue (and DEP 1 says "you can submit 
corrections as GitHub issues") but it seems that Issues has been disabled 
for this repository. Was that just an oversight?

More broadly, I think that DEP 1 makes this subject too complicated: "How 
you report a bug, or submit a DEP update depends on several factors, such 
as the maturity of the DEP, the preferences of the DEP author, and the 
nature of your comments. For the early draft stages of the DEP, it's 
probably best to send your comments and changes directly to the DEP author. 
For more mature, or finished DEPs you can submit corrections as GitHub 
issues or pull requests against the DEP repository. When in doubt about 
where to send your changes, please check first with the DEP author and/or a 
core developer."

It adds some friction to the process to ask someone to contact the DEP 
author directly to ask them whether or not they should contact them 
directly with their comments. I think it would be more straightforward to 
just use the usual complement of open-source tools that we all know and 
love: the developers mailing list, pull requests, and an issue tracker.

I would have filed this as an issue, but... :-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3cc307c1-c329-4ffb-9848-ac0470731207%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: change commit message format to present tense?

[Kevin Christopher Henry]

If anyone's put off by the hectoring tone of the imperative mood, it might 
be better to think of it as the indicative mood. That is:

(This will) "add password validation to prevent the usage of...".

rather than

(You must) "add password validation to prevent the usage of..."!

In English they're usually expressed the same way, but not so in other 
languages. Anecdotally, I saw someone comment that in Portuguese the two 
are different and that the indicative, but not the imperative, would make 
sense for a commit message. Reinout, I'm curious if that distinction would 
make a difference in your native language?

For what it's worth, I'm in favor of both proposed changes.

Cheers,
Kevin

On Saturday, June 25, 2016 at 9:29:15 PM UTC-4, Tim Graham wrote:
>
> Reinout, I agree that the imperative mood seems awkward, especially when 
> reading history, but of course I'm influenced by my experience with 
> Django's history. No doubt others find it more natural. I guess if I had my 
> way, we would keep using past tense, although I will say that it gets a bit 
> tiresome correcting the messages of contributors who don't read our 
> contributing guidelines.
>
> Shai, about "Why don't we accept both?" -- I think it's nice to have a 
> standard format so we don't have to parse visual differences when browsing 
> git log.
>
> On Saturday, June 25, 2016 at 10:23:59 AM UTC-4, Reinout van Rees wrote:
>>
>> Op 24-06-16 om 19:48 schreef Carl Meyer: 
>> > To be clear, the recommended git style is not present tense, it is 
>> > imperative mood. So it should _not_ be "Fixes #12345 -- Regulates the 
>> > frobnicator", it should be "Fix #12345 -- Regulate the frobnicator." 
>>
>> Everybody seems to be in favour. I'll allow myself a small question mark 
>> anyway. 
>>
>> Why? Well, django is well-known for its excellent documentation. Take 
>> for instance the release notes. Here's a snippet: 
>>
>> "Django now offers password validation to help prevent the usage of weak 
>> passwords by users." 
>>
>> That is how we communicate with our users. 
>>
>> Now back to commit messages and code. Code should be written for humans 
>> reading it, not for computers executing it, right? Readability counts. 
>> Now if I read the history of a file I'd expect to read something that's 
>> pretty readable to me as a developer. I expect to read what happened: 
>>
>> "Added password validation to help prevent the usage of..." 
>>
>>
>> Instead I'll now see commit messages like this: 
>>
>> "Add password validation to prevent the usage of..." 
>>
>> Linguistically, I'm getting an imperative order to do something. And I 
>> have to translate it to a sentence that actually makes sense. Every 
>> django programmer has to make that mental switch/translation. 
>>
>> Is that a cost we want to pay? Does it fit in with our tradition of 
>> providing good documentation? Are we taking linguistic advise from the 
>> people who brought us git's user interface instead of from our English 
>> teachers? 
>>
>> We don't have to order git to do something, we have to communicate what 
>> we've done to fellow programmers. 
>>
>>
>>
>> I'm not a native English speaker, so I might be missing some nuances. 
>> Perhaps it is less weird if you're a native speaker. 
>>
>> Reinout 
>>
>> -- 
>> Reinout van Rees  http://reinout.vanrees.org/ 
>> rei...@vanrees.org   http://www.nelen-schuurmans.nl/ 
>> "Learning history by destroying artifacts is a time-honored atrocity" 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/24da9fcf-7a9e-4cde-8af6-8673fdcaebaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving Windows users experience at the command line

[Kevin Christopher Henry]

Regarding venv and bash, I filed a ticket [1] three years ago to have the 
bash script included with the Windows venv installation, and it looks like 
that change is in from 3.5 on. So in any case we shouldn't need to suggest 
virtualenv any more.

Although I personally use bash, I definitely agree that it would nice to 
have a Windows-native solution that Just Works, so +1 from this occasional 
Windows user.

Cheers,
Kevin

[1] https://bugs.python.org/issue22343

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97d24976-0ea4-424a-90c0-b39b0934bca6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.