Re: Settings: lists or tuples?

[Ryan Hiebert]

> On Dec 18, 2014, at 12:49 AM, Russell Keith-Magee  
> wrote:
> 
> So - I retract my suggestion - I think I can live with just documenting this 
> as a backwards compatibility.

Sounds good. In case anyone is interested, I made a pull request (not complete) 
with an implementation of a ‘ConfList’ that could detect operations with 
tuples. Scrapping it doesn’t bother me, it was a fun challenge. Perhaps someone 
else will think it’s interesting too.

https://github.com/django/django/pull/3752

-- 
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/9DB0375E-4772-43A9-9936-F137B616211E%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bypassing 1.7+ migrations

[Markus Holtermann]

Hey Shai,

manage=False won't gain you anything, since those models will still show
up in migrations, because they need to be able to be referenced by
managed models. The migration database operations are noops though.

/Markus

On Thu, Dec 18, 2014 at 06:08:52AM +0200, Shai Berger wrote:

FWIW, the approach I would go for is to try to monkeypatch
managed=False into the base model Meta.

Shai.

On Tuesday 16 December 2014 14:49:25 Andrew Godwin wrote:

Hi Marcin,

You can't bypass migrations as much as you can't bypass syncdb; that is,
the commands are separate and you can choose not to run them (or just
delete the migration files). As far as I can tell your only issue is the
runserver warning that you have unmigrated changes, which there's currently
no plan to be able to disable.

Also bear in mind that, by doing your own schema management for the contrib
apps, you're kind of implicitly forking the schema; Django 1.8 will ship
with some migrations for these apps, and you're going to have to make sure
you manage those yourself and keep the database in sync with the code
(though of course the release notes will mention this kind of thing).

If you want to stub out migration operations, you can just make a custom
database backend that inherits from the one you use and define a new
SchemaEditor subclass with an execute() function that does nothing; that
should accomplish what you want. Alternatively, you could wrap all
migration operations into the State side of SeparateDatabaseAndState, but
that's a bit cumbersome.

Andrew

On Tue, Dec 16, 2014 at 4:42 AM, Marcin Nowak 

wrote:
> Hi Andrew,
>
> Thanks for a reply. But as I've mentioned above I can't set managed=False
> on models delivered from external apps like django.contrib.auth,
> django.contrib.sessions, and many more. Forking them is not an option.
>
> I think that bypassing migrations should be possible via some setting.
> That's why I wrote to developers forum directly.
> Please think about that.
>
> Marcin
>
> On Tuesday, December 16, 2014 1:34:17 PM UTC+1, Andrew Godwin wrote:
>> Hi Marcin,
>>
>> If you're using an external tool to manage schemas of models, just set
>> managed=False on the models and Django will stop trying to change their
>> schemas (including stopping making migrations for them).
>>
>> Andrew
>>
>> On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak 
>>
>> wrote:
>>> Hello!
>>>
>>> I'm using Django as a part of bigger stack where I'm using external
>>> tool to manage database migrations.
>>> After migration to Django 1.7 I'm encouraged at every runserver command
>>> to execute some migrations, which may blow my databases.
>>>
>>> I want to bypass Django migrations to prevent any schema modification.
>>> I can bypass migrate*  commands by overriding them in my custom app,
>>> but this is a little tricky and does not cover all cases. Using
>>> managed=False is not a solution, because none of reusable apps have
>>> models defined as unmanaged (same for django.contrib, especially auth
>>> and sessions).
>>> That's why I need to bypass migrations globally.
>>>
>>> Have you ever considered possibility to allow disabling it? Maybe via
>>> some setting to use kind a DummyMigrationExecutor instead of
>>> MigrationExecutor?
>>>
>>> Cheers,
>>> Marcin
>>>
>>>  --
>>>
>>> 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-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.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/a27293a1-4212-4a2a-ae44-
>>> 4720fc674162%40googlegroups.com
>>> >> -ae44-4720fc674162%40googlegroups.com?utm_medium=email&utm_source=foote
>>> r> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
>
> 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/d8226a81-9dfe-4019-94
> ce-98beb6e1bf04%40googlegroups.com
>  94ce-98beb6e1bf04%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.


--

--
You received this message because you are subscribed to the Google Groups "Django 
developers

Re: Settings: lists or tuples?

[Russell Keith-Magee]

On Thu, Dec 18, 2014 at 7:48 AM, Carl Meyer  wrote:
>
> On 12/17/2014 04:39 PM, Russell Keith-Magee wrote:
> > On Thu, Dec 18, 2014 at 5:03 AM, Aymeric Augustin <
> > aymeric.augus...@polytechnique.org> wrote:
> >
> >> On 17 déc. 2014, at 21:54, Carl Meyer  wrote:
> >>
> >>> So I think there is a backwards-compatibility issue.
> >>
> >> Indeed.
> >>
> >>> Personally, I would love to decide to just bite this bullet and
> >>> normalize to lists, but I think it would need to be marked as a
> >>> backwards-incompatibility in the release notes, and it would certainly
> >>> bite people.
> >>
> >> We can do that. The error is easy to fix if it occurs. Technically
> >> django.conf.global_settings is a private API.
> >>
> >> But I feel guilty to break code just for consistency and aesthetics :-/
> >>
> >
> > I agree that lists are preferable to tuples.
> >
> > As for backwards incompatibility: we can update the new project template,
> > and we can update the docs; but I don't think we can play the
> > "global_settings is internal API" card here. The file global_settings
> might
> > not be formally documented, but the contents are, and the default
> settings
> > provided by Django are documented; and even if they weren't, this is a
> high
> > traffic area of the Django API.
> >
> > One option for handling existing projects might be to define our own
> > subclass of list that defines __add__, __iadd__, and __radd__ such that
> it
> > will accept a tuple, converting to a list, and raise a
> DeprecationWarning;
> > in a later version, we can replace that subclass with a simple list. We
> > wouldn't document this class, and it would only be used in
> > global_settings.py. This would cover the most common use case (adding
> > something to a default setting), and provide a migration path. Thoughts?
>
> This is clever, but on second thought I'm trying to figure out in what
> scenario a backwards-compatibility would actually occur here. In the
> context of a user's settings modules, global_settings plays no role at
> all: you can't add to a global setting default in your settings.py
> (unless you've imported global_settings yourself, which is certainly
> making use of undocumented internals).
>
> So it seems to me that the only scenario in which this would actually
> cause a back-compat problem would be if someone is using a tuple
> setting, which they are not setting themselves (and thus are using the
> global default), and they are adding to it in their runtime code (not in
> their settings file). For instance:
>
> my_ctx_procs = settings.TEMPLATE_CONTEXT_PROCESSORS + ('another',)
>
> The common case of appending to a setting in your settings.py (due to
> use of some kind of split-settings) should not be impacted at all
>

That's a fair point. The benefit for an __add__ definition is likely to be
a lot smaller than I originally thought.

The only place I can think that it might pop up is in older (pre
@override_settings) test harnesses; that said, a failure during test isn't
a major inconvenience

So - I retract my suggestion - I think I can live with just documenting
this as a backwards compatibility.

Yours,
Russ Magee %-)

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

Re: annotate() and generic relations

[Shai Berger]

Hi Anssi,

Thanks for that quick fix.

On Wednesday 17 December 2014 10:16:27 Anssi Kääriäinen wrote:
> 
> It turns out this is easy to fix. There is a patch for this at
> https://github.com/django/django/pull/3743.
> 
(All: In case you're interested but lazy -- this was committed)

> The generic relations still work a bit differently to that of reverse
> foreign key - where reverse foreign keys can be filtered
> with .filter(reverse_relation=some_related_object), that doesn't work
> with reverse relations, instead you have to explicitly provide the
> primary key value by doing .filter(generic_rel=some_related_object.pk).

So, I'm not sure if we should document this behavior or try to fix it as well.

I opened #24019 for fixing the outdated "GenericRelation+aggregation don't 
work" documentation, and added that as a point for consideration as well.

Thanks again,
Shai.

Re: Bypassing 1.7+ migrations

[Shai Berger]

FWIW, the approach I would go for is to try to monkeypatch 
managed=False into the base model Meta.

Shai.

On Tuesday 16 December 2014 14:49:25 Andrew Godwin wrote:
> Hi Marcin,
> 
> You can't bypass migrations as much as you can't bypass syncdb; that is,
> the commands are separate and you can choose not to run them (or just
> delete the migration files). As far as I can tell your only issue is the
> runserver warning that you have unmigrated changes, which there's currently
> no plan to be able to disable.
> 
> Also bear in mind that, by doing your own schema management for the contrib
> apps, you're kind of implicitly forking the schema; Django 1.8 will ship
> with some migrations for these apps, and you're going to have to make sure
> you manage those yourself and keep the database in sync with the code
> (though of course the release notes will mention this kind of thing).
> 
> If you want to stub out migration operations, you can just make a custom
> database backend that inherits from the one you use and define a new
> SchemaEditor subclass with an execute() function that does nothing; that
> should accomplish what you want. Alternatively, you could wrap all
> migration operations into the State side of SeparateDatabaseAndState, but
> that's a bit cumbersome.
> 
> Andrew
> 
> On Tue, Dec 16, 2014 at 4:42 AM, Marcin Nowak 
> 
> wrote:
> > Hi Andrew,
> > 
> > Thanks for a reply. But as I've mentioned above I can't set managed=False
> > on models delivered from external apps like django.contrib.auth,
> > django.contrib.sessions, and many more. Forking them is not an option.
> > 
> > I think that bypassing migrations should be possible via some setting.
> > That's why I wrote to developers forum directly.
> > Please think about that.
> > 
> > Marcin
> > 
> > On Tuesday, December 16, 2014 1:34:17 PM UTC+1, Andrew Godwin wrote:
> >> Hi Marcin,
> >> 
> >> If you're using an external tool to manage schemas of models, just set
> >> managed=False on the models and Django will stop trying to change their
> >> schemas (including stopping making migrations for them).
> >> 
> >> Andrew
> >> 
> >> On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak 
> >> 
> >> wrote:
> >>> Hello!
> >>> 
> >>> I'm using Django as a part of bigger stack where I'm using external
> >>> tool to manage database migrations.
> >>> After migration to Django 1.7 I'm encouraged at every runserver command
> >>> to execute some migrations, which may blow my databases.
> >>> 
> >>> I want to bypass Django migrations to prevent any schema modification.
> >>> I can bypass migrate*  commands by overriding them in my custom app,
> >>> but this is a little tricky and does not cover all cases. Using
> >>> managed=False is not a solution, because none of reusable apps have
> >>> models defined as unmanaged (same for django.contrib, especially auth
> >>> and sessions).
> >>> That's why I need to bypass migrations globally.
> >>> 
> >>> Have you ever considered possibility to allow disabling it? Maybe via
> >>> some setting to use kind a DummyMigrationExecutor instead of
> >>> MigrationExecutor?
> >>> 
> >>> Cheers,
> >>> Marcin
> >>> 
> >>>  --
> >>> 
> >>> 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-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.
> >>> To view this discussion on the web visit https://groups.google.com/d/
> >>> msgid/django-developers/a27293a1-4212-4a2a-ae44-
> >>> 4720fc674162%40googlegroups.com
> >>>  >>> -ae44-4720fc674162%40googlegroups.com?utm_medium=email&utm_source=foote
> >>> r> .
> >>> For more options, visit https://groups.google.com/d/optout.
> >>> 
> >>  --
> > 
> > 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/d8226a81-9dfe-4019-94
> > ce-98beb6e1bf04%40googlegroups.com
> >  > 94ce-98beb6e1bf04%40googlegroups.com?utm_medium=email&utm_source=footer>
> > .
> > 
> > For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Ryan Hiebert]

> On Dec 17, 2014, at 6:12 PM, Carl Meyer  wrote:
> 
> On 12/17/2014 04:57 PM, Ryan Hiebert wrote:
>>> 
>> What would __iadd__ do in this subclass? Would it behave like tuple and
>> create a new DjangoList, or would it behave like list and extend the
>> original list?
> 
> For maximum backwards-compatibility during the deprecation period, if
> it's called with a tuple, it should create and return a new tuple, I
> think. That way the deprecation warning only gets fired once for a
> particular setting, which is all that's needed, even if they go and add
> to the resulting value several more times.
> 
> If it's called with a list, it should behave as a normal list does.
> 
> And before you get too far, you may want to wait and see if any other
> core devs step in to tell me I'm crazy and there's no way we should have
> a deprecation path just to switch some settings from tuples to lists.
> 
> (I'm only in favor of it myself because I think in practice the impact
> will be small.)

Thanks for the warning, and your solution makes perfect sense to me.
I’m gonna go ahead and keep working on it for fun, but I understand
that we might find that it’s not worth the deprecation period, and
I’m OK with that.

Thinking about it a bit, I’m going to see if just watching for tuple
and returning a tuple, otherwise returning a native list might be
sufficient.

Ryan

-- 
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/8B6067E2-43DF-454A-BC0C-3928239F7C5B%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Carl Meyer]

On 12/17/2014 04:57 PM, Ryan Hiebert wrote:
> 
>> On Dec 17, 2014, at 5:48 PM, Carl Meyer  wrote:
>>
>> On 12/17/2014 04:39 PM, Russell Keith-Magee wrote:
>>>
>>> I agree that lists are preferable to tuples.
>>>
>>> One option for handling existing projects might be to define our own
>>> subclass of list that defines __add__, __iadd__, and __radd__ such that it
>>> will accept a tuple, converting to a list, and raise a DeprecationWarning;
>>> in a later version, we can replace that subclass with a simple list. We
>>> wouldn't document this class, and it would only be used in
>>> global_settings.py. This would cover the most common use case (adding
>>> something to a default setting), and provide a migration path. Thoughts?
>>
>> FWIW, I think the subclass-of-list approach is neat enough, I'd be in
>> favor of going ahead and doing this with that approach, if someone's
>> motivated to write the patch.
>>
> What would __iadd__ do in this subclass? Would it behave like tuple and
> create a new DjangoList, or would it behave like list and extend the
> original list?

For maximum backwards-compatibility during the deprecation period, if
it's called with a tuple, it should create and return a new tuple, I
think. That way the deprecation warning only gets fired once for a
particular setting, which is all that's needed, even if they go and add
to the resulting value several more times.

If it's called with a list, it should behave as a normal list does.

And before you get too far, you may want to wait and see if any other
core devs step in to tell me I'm crazy and there's no way we should have
a deprecation path just to switch some settings from tuples to lists.

(I'm only in favor of it myself because I think in practice the impact
will be small.)

Carl

-- 
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/54921BFD.9040809%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Settings: lists or tuples?

[Ryan Hiebert]

> On Dec 17, 2014, at 5:48 PM, Carl Meyer  wrote:
> 
> On 12/17/2014 04:39 PM, Russell Keith-Magee wrote:
>> 
>> I agree that lists are preferable to tuples.
>> 
>> One option for handling existing projects might be to define our own
>> subclass of list that defines __add__, __iadd__, and __radd__ such that it
>> will accept a tuple, converting to a list, and raise a DeprecationWarning;
>> in a later version, we can replace that subclass with a simple list. We
>> wouldn't document this class, and it would only be used in
>> global_settings.py. This would cover the most common use case (adding
>> something to a default setting), and provide a migration path. Thoughts?
> 
> FWIW, I think the subclass-of-list approach is neat enough, I'd be in
> favor of going ahead and doing this with that approach, if someone's
> motivated to write the patch.
> 
What would __iadd__ do in this subclass? Would it behave like tuple and
create a new DjangoList, or would it behave like list and extend the
original list?

I’m interested at taking a whack at it, though I can imagine somebody else
getting it done faster.

Ryan

-- 
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/D0921E76-49EC-4750-8013-DE117AEC5544%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Carl Meyer]

On 12/17/2014 04:39 PM, Russell Keith-Magee wrote:
> On Thu, Dec 18, 2014 at 5:03 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> 
>> On 17 déc. 2014, at 21:54, Carl Meyer  wrote:
>>
>>> So I think there is a backwards-compatibility issue.
>>
>> Indeed.
>>
>>> Personally, I would love to decide to just bite this bullet and
>>> normalize to lists, but I think it would need to be marked as a
>>> backwards-incompatibility in the release notes, and it would certainly
>>> bite people.
>>
>> We can do that. The error is easy to fix if it occurs. Technically
>> django.conf.global_settings is a private API.
>>
>> But I feel guilty to break code just for consistency and aesthetics :-/
>>
> 
> I agree that lists are preferable to tuples.
> 
> As for backwards incompatibility: we can update the new project template,
> and we can update the docs; but I don't think we can play the
> "global_settings is internal API" card here. The file global_settings might
> not be formally documented, but the contents are, and the default settings
> provided by Django are documented; and even if they weren't, this is a high
> traffic area of the Django API.
> 
> One option for handling existing projects might be to define our own
> subclass of list that defines __add__, __iadd__, and __radd__ such that it
> will accept a tuple, converting to a list, and raise a DeprecationWarning;
> in a later version, we can replace that subclass with a simple list. We
> wouldn't document this class, and it would only be used in
> global_settings.py. This would cover the most common use case (adding
> something to a default setting), and provide a migration path. Thoughts?

This is clever, but on second thought I'm trying to figure out in what
scenario a backwards-compatibility would actually occur here. In the
context of a user's settings modules, global_settings plays no role at
all: you can't add to a global setting default in your settings.py
(unless you've imported global_settings yourself, which is certainly
making use of undocumented internals).

So it seems to me that the only scenario in which this would actually
cause a back-compat problem would be if someone is using a tuple
setting, which they are not setting themselves (and thus are using the
global default), and they are adding to it in their runtime code (not in
their settings file). For instance:

my_ctx_procs = settings.TEMPLATE_CONTEXT_PROCESSORS + ('another',)

The common case of appending to a setting in your settings.py (due to
use of some kind of split-settings) should not be impacted at all.

I guess this is still enough of a backwards-incompatibility that we
should have a deprecation process, but it won't bite nearly as many
people as I'd initially thought it would.

FWIW, I think the subclass-of-list approach is neat enough, I'd be in
favor of going ahead and doing this with that approach, if someone's
motivated to write the patch.

Carl

-- 
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/5492164A.4020705%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Settings: lists or tuples?

[Russell Keith-Magee]

On Thu, Dec 18, 2014 at 5:03 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 17 déc. 2014, at 21:54, Carl Meyer  wrote:
>
> > So I think there is a backwards-compatibility issue.
>
> Indeed.
>
> > Personally, I would love to decide to just bite this bullet and
> > normalize to lists, but I think it would need to be marked as a
> > backwards-incompatibility in the release notes, and it would certainly
> > bite people.
>
> We can do that. The error is easy to fix if it occurs. Technically
> django.conf.global_settings is a private API.
>
> But I feel guilty to break code just for consistency and aesthetics :-/
>

I agree that lists are preferable to tuples.

As for backwards incompatibility: we can update the new project template,
and we can update the docs; but I don't think we can play the
"global_settings is internal API" card here. The file global_settings might
not be formally documented, but the contents are, and the default settings
provided by Django are documented; and even if they weren't, this is a high
traffic area of the Django API.

One option for handling existing projects might be to define our own
subclass of list that defines __add__, __iadd__, and __radd__ such that it
will accept a tuple, converting to a list, and raise a DeprecationWarning;
in a later version, we can replace that subclass with a simple list. We
wouldn't document this class, and it would only be used in
global_settings.py. This would cover the most common use case (adding
something to a default setting), and provide a migration path. Thoughts?

Yours,
Russ Magee %-)

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

Re: Migrations in Django 1.7 make unit testing models harder

[cc]

At the risk of reviving an old topic, I wanted to add one significant point 
in favor of (and mitigation for) running tests with migrations disabled: 
Speed.

Creating a test DB in sqlite for our project (~100 database tables) takes 
approximately 1-2 minutes on most developer machines. 1-2 minutes of idle 
time to run any test was just unacceptable so we disabled migrations by 
setting fake migrations in MIGRATION_MODULES and brought the test DB 
creation time down to about 5 seconds (!!).

However the risk of committing invalid code because someone forgot to 
makemigrations is real. We've addressed it by only overriding migrations on 
our local test settings and still having migrations run on our CI server. 
We have our CI server use settings.test, while developers running tests on 
their local machine use settings.test_local which is just:

from settings.test import *

MIGRATION_MODULES = ((app, '%s.fake_migrations' % app) for app in 
INSTALLED_APPS)


This seems to get us the best of both worlds. I was surprised to read 
through this thread and not see other mentions of the performance 
implications of running migrations on every test run. I'd be curious to 
hear if this has been a bottleneck for other teams.

-Chris

On Tuesday, March 25, 2014 10:21:51 AM UTC-7, Bernie Sumption wrote:

> Hi Django devs,
>
> I've just started a new project in 1.7b, and the development experience 
> working with unit tests on models is more complicated than it was in 1.6. 
> It's all down to how the throwaway test databases are created. In 1.6, the 
> create_test_db function "Creates a new test database and runs syncdb 
> against it." In 1.7, it runs "migrate".
>
> While generally speaking, migrate is the new syncdb, this behaviour is not 
> ideal for tests. In 1.6 "syncdb" created a database reflecting the current 
> state of the models in models.py. "migrate" creates a database reflecting 
> the state of the models at the last time makemigrations was run. If you're 
> doing TDD and constantly making small changes to your models then runnning 
> unit tests, you have to run makemigrations before each test run to get your 
> tests to work. You therefore end up with many tiny migration files 
> representing the minute-by-minute history of development.
>
> I came up with a pretty effective workaround that is working for me, but I 
> thought I'd post this here as others are sure to encounter this issue, and 
> I think that it makes more sense for the behaviour produced by this 
> workaround to be the default for running tests.
>
> If makemigrations has not yet been run, the "migrate" command treats an 
> app as unmigrated, and creates tables directly from the models just like 
> syncdb did in 1.6. I defined a new settings module just for unit tests 
> called "settings_test.py", which imports * from the main settings module 
> and adds this line:
>
> MIGRATION_MODULES = {"myapp": "myapp.migrations_not_used_in_tests"}
>
> Then I run tests like this:
>
> DJANGO_SETTINGS_MODULE="myapp.settings_test" python manage.py test
>
> This fools migrate into thinking that the app is unmigrated, and so every 
> time a test database is created it reflects the current structure of 
> models.py.
>
> So my feature request is as follows:
>
> If the new behaviour is by design and considered desirable, then it is a 
> big change from the previous version and should be prominently documented 
> in the migrations and testing pages, along with the workaround. I'm happy 
> to write this documentation if that's the way you want to go.
>
> However, if the new behaviour is not by design but just a by-product of 
> the new migrations feature, I suggest making the workaround the default 
> behaviour. I don't (yet!) know enough about Django internals to volunteer 
> for this however.
>
> Thanks for your time,
>
> Bernie :o)
>
>

-- 
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/371a1e36-b752-4dad-8bc8-08c8b643e9c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Andrea Corbellini]

On Wed, Dec 17, 2014 at 9:48 PM, Aymeric Augustin 
 wrote:
Surprisingly, it seems that there isn’t a backwards compatibility 
problem with changing the type to lists, as the following pattern 
still works:


# myproject/settings.py
from django.conf.global_settings import FILE_UPLOAD_HANDLERS
FILE_UPLOAD_HANDLERS += 
('myproject.uploadhandler.FooBarUploadHandler',)


Proof:


 foo = ['abc']
 foo += ('def',)
 foo

['abc', ‘def’]


Well, technically, there is a potential backward incompatibility: += 
for lists is a synonym for .extend().


Proof:

>>> a = [1,2,3]
>>> b = a
>>> b += (4,)
>>> a
[1, 2, 3, 4]
>>> b
[1, 2, 3, 4]


>>> a = (1,2,3)
>>> b = a
>>> b += (4,)
>>> a
(1, 2, 3)
>>> b
(1, 2, 3, 4)

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

Re: Settings: lists or tuples?

[Collin Anderson]

I agree lists are the way to go. I have heard that tuples are faster, but I 
don't think that outweighs comma issue and inconsistency.

global_settings isn't completely undocumented, based on greping the docs. 
Seems to me we should at least make the docs and project_template 
consistent and use lists everywhere.

On Wednesday, December 17, 2014 4:04:22 PM UTC-5, Aymeric Augustin wrote:
>
> On 17 déc. 2014, at 21:54, Carl Meyer > 
> wrote: 
>
> > So I think there is a backwards-compatibility issue. 
>
> Indeed. 
>
> > Personally, I would love to decide to just bite this bullet and 
> > normalize to lists, but I think it would need to be marked as a 
> > backwards-incompatibility in the release notes, and it would certainly 
> > bite people. 
>
> We can do that. The error is easy to fix if it occurs. Technically 
> django.conf.global_settings is a private API. 
>
> But I feel guilty to break code just for consistency and aesthetics :-/ 
>
> -- 
> Aymeric. 
>
>
>
>
>

-- 
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/02dd5042-6b79-4d1c-8c80-0559e69fb53f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Aymeric Augustin]

On 17 déc. 2014, at 21:54, Carl Meyer  wrote:

> So I think there is a backwards-compatibility issue.

Indeed.

> Personally, I would love to decide to just bite this bullet and
> normalize to lists, but I think it would need to be marked as a
> backwards-incompatibility in the release notes, and it would certainly
> bite people.

We can do that. The error is easy to fix if it occurs. Technically
django.conf.global_settings is a private API.

But I feel guilty to break code just for consistency and aesthetics :-/

-- 
Aymeric.




-- 
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/235A3769-154B-48E3-B40B-91181BB97ADA%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Michael Manfre]

+1 for lists.

On Wed, Dec 17, 2014 at 3:54 PM, Carl Meyer  wrote:
>
> On 12/17/2014 01:48 PM, Aymeric Augustin wrote:
> > I’m about to introduce a new setting that is a sequence of things,
> TEMPLATES, and I have to decide whether it will be a tuple of a list.
> >
> > Unfortunately Django is very inconsistent in the type of settings. In
> global_settings.py:
> >
> > - 22 settings are tuples
> >   - 10 are empty, 12 aren't
> >   - 12 are referred to as “lists” in code comments, 1 as “tuple”
> > - 6 settings are lists
> >   - all of them are empty
> >
> > Even the tutorial is inconsistent. The first two settings described are:
> >
> > - INSTALLED_APPS: example is a tuple
> > - TEMPLATE_DIRS: example is a list
> >
> > It would be nice to standardize on tuples or lists — at least for new
> code if it’s undesirable to change the existing code.
> >
> > This is purely a matter of consistency and aesthetics. Using a tuple or
> a list never makes any difference in the code.
> >
> > While lists are less common than tuples currently, I prefer them for two
> reasons:
> >
> > 1) All these settings are sequences of similar things. Such values are
> best represented with lists, unless they have to be immutable, in which
> case a tuple can be used. (tuples are both “namedtuples without names” and
> “immutable lists” in Python.)
> >
> > 2) Lists aren’t prone to the “missing comma in single-item tuple”
> problem which bites beginners and experienced pythonistas alike. Django
> even has code to defend against this mistake for a handful of settings.
> Search for “tuple_settings” in the source.
>
> I agree with your preference for lists, for the same two reasons.
>
> > Surprisingly, it seems that there isn’t a backwards compatibility
> problem with changing the type to lists, as the following pattern still
> works:
> >
> > # myproject/settings.py
> > from django.conf.global_settings import FILE_UPLOAD_HANDLERS
> > FILE_UPLOAD_HANDLERS += ('myproject.uploadhandler.FooBarUploadHandler',)
> >
> > Proof:
> >
>  foo = ['abc']
>  foo += ('def',)
>  foo
> > ['abc', ‘def’]
> >
> > I can’t think of another circumstance it which the type of the default
> value will make a difference.
> >
> > So… can we normalize the code and satisfy my OCD? Or should I just stop
> caring and move on? ;-)
>
> Unfortunately `__iadd__` and `__add__` do not have the same behavior here:
>
> >>> foo = ['abc']
> >>> foo = foo + ('def',)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: can only concatenate list (not "tuple") to list
>
> So I think there is a backwards-compatibility issue.
>
> Personally, I would love to decide to just bite this bullet and
> normalize to lists, but I think it would need to be marked as a
> backwards-incompatibility in the release notes, and it would certainly
> bite people.
>
> Carl
>
> --
> 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/5491ED93.2080506%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Settings: lists or tuples?

[Carl Meyer]

On 12/17/2014 01:48 PM, Aymeric Augustin wrote:
> I’m about to introduce a new setting that is a sequence of things, TEMPLATES, 
> and I have to decide whether it will be a tuple of a list.
> 
> Unfortunately Django is very inconsistent in the type of settings. In 
> global_settings.py:
> 
> - 22 settings are tuples
>   - 10 are empty, 12 aren't
>   - 12 are referred to as “lists” in code comments, 1 as “tuple”
> - 6 settings are lists
>   - all of them are empty
> 
> Even the tutorial is inconsistent. The first two settings described are:
> 
> - INSTALLED_APPS: example is a tuple
> - TEMPLATE_DIRS: example is a list
> 
> It would be nice to standardize on tuples or lists — at least for new code if 
> it’s undesirable to change the existing code.
> 
> This is purely a matter of consistency and aesthetics. Using a tuple or a 
> list never makes any difference in the code.
> 
> While lists are less common than tuples currently, I prefer them for two 
> reasons:
> 
> 1) All these settings are sequences of similar things. Such values are best 
> represented with lists, unless they have to be immutable, in which case a 
> tuple can be used. (tuples are both “namedtuples without names” and 
> “immutable lists” in Python.)
> 
> 2) Lists aren’t prone to the “missing comma in single-item tuple” problem 
> which bites beginners and experienced pythonistas alike. Django even has code 
> to defend against this mistake for a handful of settings. Search for 
> “tuple_settings” in the source.

I agree with your preference for lists, for the same two reasons.

> Surprisingly, it seems that there isn’t a backwards compatibility problem 
> with changing the type to lists, as the following pattern still works:
> 
> # myproject/settings.py
> from django.conf.global_settings import FILE_UPLOAD_HANDLERS
> FILE_UPLOAD_HANDLERS += ('myproject.uploadhandler.FooBarUploadHandler',)
> 
> Proof:
> 
 foo = ['abc']
 foo += ('def',)
 foo
> ['abc', ‘def’]
> 
> I can’t think of another circumstance it which the type of the default value 
> will make a difference.
> 
> So… can we normalize the code and satisfy my OCD? Or should I just stop 
> caring and move on? ;-)

Unfortunately `__iadd__` and `__add__` do not have the same behavior here:

>>> foo = ['abc']
>>> foo = foo + ('def',)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can only concatenate list (not "tuple") to list

So I think there is a backwards-compatibility issue.

Personally, I would love to decide to just bite this bullet and
normalize to lists, but I think it would need to be marked as a
backwards-incompatibility in the release notes, and it would certainly
bite people.

Carl

-- 
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/5491ED93.2080506%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Settings: lists or tuples?

[Aymeric Augustin]

Hello,

I’m about to introduce a new setting that is a sequence of things, TEMPLATES, 
and I have to decide whether it will be a tuple of a list.

Unfortunately Django is very inconsistent in the type of settings. In 
global_settings.py:

- 22 settings are tuples
- 10 are empty, 12 aren't
- 12 are referred to as “lists” in code comments, 1 as “tuple”
- 6 settings are lists
- all of them are empty

Even the tutorial is inconsistent. The first two settings described are:

- INSTALLED_APPS: example is a tuple
- TEMPLATE_DIRS: example is a list

It would be nice to standardize on tuples or lists — at least for new code if 
it’s undesirable to change the existing code.

This is purely a matter of consistency and aesthetics. Using a tuple or a list 
never makes any difference in the code.

While lists are less common than tuples currently, I prefer them for two 
reasons:

1) All these settings are sequences of similar things. Such values are best 
represented with lists, unless they have to be immutable, in which case a tuple 
can be used. (tuples are both “namedtuples without names” and “immutable lists” 
in Python.)

2) Lists aren’t prone to the “missing comma in single-item tuple” problem which 
bites beginners and experienced pythonistas alike. Django even has code to 
defend against this mistake for a handful of settings. Search for 
“tuple_settings” in the source.

Surprisingly, it seems that there isn’t a backwards compatibility problem with 
changing the type to lists, as the following pattern still works:

# myproject/settings.py
from django.conf.global_settings import FILE_UPLOAD_HANDLERS
FILE_UPLOAD_HANDLERS += ('myproject.uploadhandler.FooBarUploadHandler',)

Proof:

>>> foo = ['abc']
>>> foo += ('def',)
>>> foo
['abc', ‘def’]

I can’t think of another circumstance it which the type of the default value 
will make a difference.

So… can we normalize the code and satisfy my OCD? Or should I just stop caring 
and move on? ;-)

-- 
Aymeric.



-- 
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/6840953C-B5CA-4575-BBA1-90CD9E880C58%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Windows users around?

[Claude Paroz]

Hey,

I'm one of the most Windows-breaking committers, also because I don't care 
any more for this system. Sorry for that! (for you, not for me :-)

Tim kindly pointed me to the following list of tickets which need love from 
some Windows users of Django:
https://code.djangoproject.com/query?status=!closed&keywords=~windows-test-failure

So if you are concerned and have a bit of time, please give some attention 
to the aforementioned tickets.

Thanks.

Claude

-- 
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/eb188de6-290d-4303-a838-03c751729a40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Bobby Mozumder]

For the Documentation, one suggestion I have is that the body font that’s more 
different from the source code font.

It looks like you’re using Roboto (a Helvetica clone) for the body text and 
Incosolota for the source code. They’re a little too similar.  Also, Roboto 
isn’t a good font for descriptive sentences and paragraphs.  It’s more of a 
short text font for titles, subheadline, and captions.

You generally don’t write long paragraphs with Helvetica, and you shouldn’t do 
that in Roboto either.

-bobby

-- 
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/DE43C262-BD64-4140-B82A-A046308F2EE2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Raphael Michel]

Hi,

I agree with Tino in most points.
Thanks to the volunteers who did this and I really love the fact,
that I can finally browse the docs on a mobile device. Great!

But there certainly is a loss of both originality and the readability.
Both of these things are no blockers and don't make the new design
really bad, but both are things worth improving.

For originality, bringing back some of the old colors could help. They
suited Django very well and looked less like a million other pages out
there. I can't really help here, as I am no talented designer.

For readability, I like Tino's suggestion as well as the tickets [1]
and [2]. I think with minor improvements like a modified line height,
more bold headlines and more contrast in boxes and code, this
documentation could be both as modern as the new design and as readable
as the old one :)

Am Wed, 17 Dec 2014 12:58:37 +0100
schrieb Tino de Bruijn :
> Does anybody agree on that and should I create a pull request?

Absolutely, sounds good!

Cheers,
Raphael


[1] https://github.com/django/djangoproject.com/issues/216
[2] https://github.com/django/djangoproject.com/issues/198

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


pgpUY8xpnNQF4.pgp
Description: Digitale Signatur von OpenPGP

Re: ANN: Django website redesign launched

[Stan]

On Wednesday, December 17, 2014 12:59:10 PM UTC+1, Tino de Bruijn wrote:
>
> Hi,
>
>
> - The font does not look crisp (can be because it's serif, or something 
> with my comp, dunno)
>

The association of *roboto* font and *-moz-osx-font-smoothing: grayscale* 
rule maybe ? 
Under code.djangoproject.com, removing the *text-shadow: 0 0* 
(trackhacks.css) rule enhance the anti-aliasing. 
 
Cheers,

Stan

-- 
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/1f2489e6-3ba7-4578-9aca-b5769d289d15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Rob]

On Wednesday, December 17, 2014 8:39:21 AM UTC-5, Daniele Procida wrote:
>
>
> We'd hate you to be "that guy" too. However, so far you are "that guy", 
> since merely announcing that you have identified numerous accessibility 
> issues is useless. 
>

Ok.  Tell the designer to google "chrome accessibility tester 
extension" and install the first match.

It will then flag the places where the Web Content Accessibility Guidelines 
are not being followed; http://www.w3.org/TR/WCAG/#visual-audio-contrast

The repository is  >.
>  
> It's all open. If you're able to suggest or make improvements, you know 
> what to do if you want to stop being "that guy". 
>

I'm not a designer.  I can't make good suggestions on how to improve 
things, since I would most definitely make it worse.
 

-- 
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/279b3513-5c92-4ec6-a878-932e6be58f79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Daniele Procida]

On Wed, Dec 17, 2014, Rob  wrote:

>On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt wrote:
>>
>> Somehow I hate it. The website is the worst website I've seen since a long 
>> time.
>> The contrast is really aweful.
>> The issue Tracker got unusable due to the colors that aren't focused on 
>> readability.
>>
>
>Clearly.  My audit extension flags 47 contrast problems on the home page 
>alone.  The site is not very accessible contrast wise.
>
>Doesn't look like a designer or a graphic guy had his hands on that.
>>
>
>It clearly had a designer,  but they don't grok usability.
>
>I hate to be "that guy" but this is not really an improvement other than it 
>works on mobile now ...

We'd hate you to be "that guy" too. However, so far you are "that guy", since 
merely announcing that you have identified numerous accessibility issues is 
useless. 

The repository is . It's all open. 
If you're able to suggest or make improvements, you know what to do if you want 
to stop being "that guy".

Daniele

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

Re: ANN: Django website redesign launched

[Rob]

On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt wrote:
>
> Somehow I hate it. The website is the worst website I've seen since a long 
> time.
> The contrast is really aweful.
> The issue Tracker got unusable due to the colors that aren't focused on 
> readability.
>

Clearly.  My audit extension flags 47 contrast problems on the home page 
alone.  The site is not very accessible contrast wise.

Doesn't look like a designer or a graphic guy had his hands on that.
>

It clearly had a designer,  but they don't grok usability.

I hate to be "that guy" but this is not really an improvement other than it 
works on mobile now ...

-- 
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/4491aa9f-9b06-4295-9411-57b9879271b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Rakan Alhneiti]

God job everyone!

Do you think the Overview page  should 
have the logos of the "Sites using Django"? it would be more visually 
appealing, in addition, people might be more aware of the logos than just 
plain names. What do you think?

Best Regards,
Rakan

On Tuesday, December 16, 2014 5:12:54 PM UTC+1, Jannis Leidel wrote:
>
> Hi everyone, 
>
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker. 
>
> This is a long time coming and we couldn't be happier to finally ship it 
> :) 
>
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues 
>
> More infos about the redesign and its history can be found in the blog 
> post: 
>
>   
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>  
>
> Happy coding, everyone! 
>
> Jannis 
>
>

-- 
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/845e4c2a-ff65-4691-b82d-02b5dfb193e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Daniele Procida]

On Wed, Dec 17, 2014, Torsten Bronger  wrote:

>> In the meantime I have removed you from our email lists, since
>> your tone is not welcome here. Please don't come back unless you
>> can communicate in a more acceptable way.
>
>Is this customary procedure on this mailing list in such cases?

People are very rarely as discourteous as that, so it doesn't happen often.

We have a code of conduct for the community 
.

>Normally one simply ignores postings/authors one doesn't like.

It wasn't something I simply didn't "like". It was unkind and disparaging 
remarks (not to mention aimed at people who had put in a lot of collaborative 
effort on behalf of the community, and at their work).

It's not acceptable here and won't be tolerated, whoever is making the remarks 
or whom they're aimed at.
 
>I hope that banned users don't have the answers to my questions.  ;-)
>Besides, a sock puppet is made in minutes ...

He's not banned; he's welcome back here at any time. It's the tone that's not 
permitted.

Daniele

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

Re: Bypassing 1.7+ migrations

[Marcin Nowak]

On Tuesday, December 16, 2014 1:49:53 PM UTC+1, Andrew Godwin wrote:
>
>
> Also bear in mind that, by doing your own schema management for the 
> contrib apps, you're kind of implicitly forking the schema; Django 1.8 will 
> ship with some migrations for these apps, and you're going to have to make 
> sure you manage those yourself and keep the database in sync with the code 
> (though of course the release notes will mention this kind of thing).
>

Yes, I'm aware of that, and I want to control every schema change (this is 
specific requirement for this project) 
 

>
> If you want to stub out migration operations, you can just make a custom 
> database backend that inherits from the one you use and define a new 
> SchemaEditor subclass with an execute() function that does nothing; that 
> should accomplish what you want. 
>

Thanks! I will try this approach. 
 

> Alternatively, you could wrap all migration operations into the State side 
> of SeparateDatabaseAndState, but that's a bit cumbersome.
>

For this I need to do some research. 
Thanks for tips!

 As far as I can tell your only issue is the runserver warning that you 
> have unmigrated changes, which there's currently no plan to be able to 
> disable.


I would like to bypass migrations to prevent accidental execution of 
`migrate` command, too.   
Generally speaking - I don't need builtin migrations (because executing 
them in my environment may be dangerous), but I need newer versions of 
Django.

I will try your tips.
 
Kind Regards,
Marcin

-- 
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/39e390e6-16a3-4591-8831-e73f281e615f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Baptiste Mispelon]

Hi Torsten,

As far as I know, it's not often that people get kicked out of this 
mailing list (note that Christian was kicked out, not banned, so he can 
join back if he'd like) so I'm not sure what's "customary".


However, we strive to create a friendly and inclusive community here, so 
toxic and insulting behavior is not simply ignored.


In this instance, I think Daniele's response was appropriate and I stand 
by it too.


I hope that answers your question.

Cheers,
Baptiste

PS: The mailing list is publicly viewable at 
https://groups.google.com/forum/#!forum/django-developers. It's only for 
posting here that you need to be registered.


On 12/17/2014 11:29 AM, Torsten Bronger wrote:

Hallöchen!

Daniele Procida writes:


[...]

In the meantime I have removed you from our email lists, since
your tone is not welcome here. Please don't come back unless you
can communicate in a more acceptable way.

Is this customary procedure on this mailing list in such cases?
Normally one simply ignores postings/authors one doesn't like.  I
hope that banned users don't have the answers to my questions.  ;-)
Besides, a sock puppet is made in minutes ...

Tschö,
Torsten.



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

Re: ANN: Django website redesign launched

[Baptiste Mispelon]

Hi Jorge,

First off, thank you for your feedback, it's very much appreciated.

Regarding your question about Trac, the differences in UI that you list 
are definitely not intended.


Ola Sitarska and me did some work to try and adapt the new design to 
Trac but it's proven to be difficult.


Could you please file some issues at 
https://github.com/django/code.djangoproject.com/issues (this is the 
repository of our Trac instance)?


If you'd like to try your hand at fixing those issues, I'd be happy to 
get you started on installing Trac locally. You can get in touch with my 
by email or on IRC (#django-websites on Freenode).



Have a nice day,
Baptiste

On 12/17/2014 11:28 AM, Jorge C. Leitão wrote:

Dear Django community,

I would like to congratulate you very much for this. I'm very pleased 
to see that the work in Django is much better presented to the world, 
which I think we all agree is an important component of the project.


Generally speaking, I like very much the overall look and feel of the 
website. I imagine it is very hard to agree on them, specially since 
it is a component that has some intrinsic subjectivity.


I have a question regarding the layout:

In the previous website there was a noticeable difference between the 
website UI and the UI of the issue tracker. Are we aiming to keep that 
difference or do we aim to make them indistinguishable?


This is because it seems that some elements of the tracker were 
changed to blend with the new look, but others don't. Specifically:


- In the main content of the issue tracker the horizontal lines have a 
shadow in the bottom; The other sections don't.
- In the issue tracker, some content is boxed (e.g. wiki), while other 
doesn't (new ticket), and the boxes are corner-rounded (while the 
website has rounded elements besides buttons).
- In the wiki of the issue tracker, the font seems to be "blurred"(?), 
compare with sidebar.


I would prefer the same look of the issue tracker for consistency, but 
since that section of the website is aimed to developers of Django, 
there can be a rational to make it different. Could we clarify this so 
we know what is a bug to report and what is an intended feature?


In any case, the quality of Django website conveys now much better the 
quality of the Django project. Thank you for that.


Cheers,
Jorge


On Tuesday, December 16, 2014 5:09:55 PM UTC+1, Jannis Leidel wrote:

Hi everyone,

We're incredibly proud to share with you the new design of the
Django website, the documentation and the issue tracker.

This is a long time coming and we couldn't be happier to finally
ship it :)

As you can imagine, there will be bugs, so please bear with us and
report issues to the issue tracker at
https://github.com/django/djangoproject.com/issues


More infos about the redesign and its history can be found in the
blog post:


https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/




Happy coding, everyone!

Jannis

--
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/c3d543e5-ac54-4df1-bd38-1d020d760fa0%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


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

Re: ANN: Django website redesign launched

[Torsten Bronger]

Hallöchen!

Daniele Procida writes:

> [...]
>
> In the meantime I have removed you from our email lists, since
> your tone is not welcome here. Please don't come back unless you
> can communicate in a more acceptable way.

Is this customary procedure on this mailing list in such cases?
Normally one simply ignores postings/authors one doesn't like.  I
hope that banned users don't have the answers to my questions.  ;-)
Besides, a sock puppet is made in minutes ...

Tschö,
Torsten.

-- 
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
  or http://bronger-jmp.appspot.com

-- 
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/87iohalgcl.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Jorge C . Leitão]

Dear Django community,

I would like to congratulate you very much for this. I'm very pleased to 
see that the work in Django is much better presented to the world, which I 
think we all agree is an important component of the project.

Generally speaking, I like very much the overall look and feel of the 
website. I imagine it is very hard to agree on them, specially since it is 
a component that has some intrinsic subjectivity.

I have a question regarding the layout:

In the previous website there was a noticeable difference between the 
website UI and the UI of the issue tracker. Are we aiming to keep that 
difference or do we aim to make them indistinguishable?

This is because it seems that some elements of the tracker were changed to 
blend with the new look, but others don't. Specifically:

- In the main content of the issue tracker the horizontal lines have a 
shadow in the bottom; The other sections don't.
- In the issue tracker, some content is boxed (e.g. wiki), while other 
doesn't (new ticket), and the boxes are corner-rounded (while the website 
has rounded elements besides buttons).
- In the wiki of the issue tracker, the font seems to be "blurred"(?), 
compare with sidebar.

I would prefer the same look of the issue tracker for consistency, but 
since that section of the website is aimed to developers of Django, there 
can be a rational to make it different. Could we clarify this so we know 
what is a bug to report and what is an intended feature?

In any case, the quality of Django website conveys now much better the 
quality of the Django project. Thank you for that.

Cheers,
Jorge


On Tuesday, December 16, 2014 5:09:55 PM UTC+1, Jannis Leidel wrote:
>
> Hi everyone, 
>
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker. 
>
> This is a long time coming and we couldn't be happier to finally ship it 
> :) 
>
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues 
>
> More infos about the redesign and its history can be found in the blog 
> post: 
>
>   
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
>  
>
> Happy coding, everyone! 
>
> Jannis 
>
>

-- 
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/c3d543e5-ac54-4df1-bd38-1d020d760fa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Daniele Procida]

On Tue, Dec 16, 2014, Schmitt, Christian  wrote:

>Somehow I hate it. The website is the worst website I've seen since a long
>time.
>The contrast is really aweful.
>The issue Tracker got unusable due to the colors that aren't focused on
>readability.
>
>Overall it looks like a mess, just to have a new design.
>
>Doesn't look like a designer or a graphic guy had his hands on that.
>I can't realized why some should replace a good and usable design which had
>some practical usage and also a good readability with the "thing" we have
>now.
>
>Sorry but I will stick to the old docs as for now or use the PDF ones with
>my custom style (since your colors are aweful, too).
>
>Django should focus on a clear design which is helpful for readability and
>not this stupid mess.

As the message you replied to indicated, various people worked very hard on 
this. 

Your comments are unkind and hurtful, and also completely useless, since they 
don't identify a single specific problem or improvement.

Here's the code ; you're welcome 
to help improve it if you can.

In the meantime I have removed you from our email lists, since your tone is not 
welcome here. Please don't come back unless you can communicate in a more 
acceptable way.

Daniele

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

Re: annotate() and generic relations

[Anssi Kääriäinen]

On Wed, 2014-12-17 at 09:21 +0200, Anssi Kääriäinen wrote:
> I investigated this a bit, and the problem is deeper in generic
> relations handling. Even filtering on generic relations use the related
> field's value, not the related model's primary key value. We should fix
> that, too.
> 
> Luckily the impact of the annotation case isn't that big. Even if the
> target would have been the related model's primary key there aren't that
> many sensible queries to run against the PK.
> 
> The impact of changing the way .filter() works might be a bit bigger,
> but I think we will need to do this as a bug fix. Case where queries
> "worked" as in they produced results but the results were incorrect are
> nasty to fix. Somebody is always relying on the incorrect results.

It turns out this is easy to fix. There is a patch for this at
https://github.com/django/django/pull/3743.

The generic relations still work a bit differently to that of reverse
foreign key - where reverse foreign keys can be filtered
with .filter(reverse_relation=some_related_object), that doesn't work
with reverse relations, instead you have to explicitly provide the
primary key value by doing .filter(generic_rel=some_related_object.pk).

 - Anssi

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

Re: ANN: Django website redesign launched

[Joe Tennies]

So, I agree sorta with what I think Christian was stating.I don't
particularly care for the color scheme. I'm making a slightly modified
markup in GIMP. I'm just wondering if there's a reason the original color
scheme was abandoned? I only ask because I actually really liked it. Was
there a driving reason as it was honestly the identity of Django in my
mind. In particular, I find it interesting that's there's an official
Django color that is usually the background to the logo (#092E20 - as
defined on https://www.djangoproject.com/community/logos/), yet that's not
the background to the logo on the main site.

That stated, I like the general content and layout now.

Quick mockup color change: http://imgur.com/DsrKIpw and
http://imgur.com/puW01nn

It's basically pulling back the old colors. (My guess is that documentation
now looks like it used to, but I can't verify.)


Obviously, if there was a good reason for the color change, then my changes
are pointless. I just think it's losing the identity.

- Joe

On Tue, Dec 16, 2014 at 5:50 PM, Alex Gaynor  wrote:
>
> Hi Christian,
>
> While I'm sure you didn't mean it this way, your email frankly makes you
> sound like an jerk, and that tone is not appropriate for this list.
>
> You've not substantiated any of your claims, other than that it your
> personal preference.
>
> If you'd like to make specific, *actionable* suggests or feedback, that's
> fine, but just shitting on other people's hard work is not.
>
> Alex
>
>
> On Tue Dec 16 2014 at 2:55:42 PM Schmitt, Christian <
> c.schm...@briefdomain.de> wrote:
>
>> Somehow I hate it. The website is the worst website I've seen since a
>> long time.
>> The contrast is really aweful.
>> The issue Tracker got unusable due to the colors that aren't focused on
>> readability.
>>
>> Overall it looks like a mess, just to have a new design.
>>
>> Doesn't look like a designer or a graphic guy had his hands on that.
>> I can't realized why some should replace a good and usable design which
>> had some practical usage and also a good readability with the "thing" we
>> have now.
>>
>> Sorry but I will stick to the old docs as for now or use the PDF ones
>> with my custom style (since your colors are aweful, too).
>>
>> Django should focus on a clear design which is helpful for readability
>> and not this stupid mess.
>>
>>
>>
>> 2014-12-16 22:48 GMT+01:00 Brad Rice :
>>>
>>> I noticed today when I went in to look something up. I like it.
>>>
>>
>>>
>>> On Tuesday, December 16, 2014 11:12:54 AM UTC-5, Jannis Leidel wrote:

 Hi everyone,

 We're incredibly proud to share with you the new design of the Django
 website, the documentation and the issue tracker.

 This is a long time coming and we couldn't be happier to finally ship
 it :)

 As you can imagine, there will be bugs, so please bear with us and
 report issues to the issue tracker at https://github.com/django/
 djangoproject.com/issues

 More infos about the redesign and its history can be found in the blog
 post:

   https://www.djangoproject.com/weblog/2014/dec/15/announcing-
 django-website-redesign/

 Happy coding, everyone!

 Jannis

  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-us...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/4a4c04ca-8e57-4351-8f1b-be30e920d64a%40googlegroups.com
>>> 
>>> .
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
>> 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/CAPDLAU6%3DHgWC_PTfRaGbQL6Tmj6tqPzcn5wdG46rkF4mBSpX0g%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group