Re: new to django... looking to contribute to learn more

[Curtis Maloney]

Well, the discussion has people saying explicitly "propose a patch /
solution and we'll talk"... as well as others saying "I think this is a
good idea".

So I'd suggest you go for it, and jump on IRC #django-dev (freenode
network) to help.

--
Curtis


On 9 February 2015 at 13:21, Bob Remeika  wrote:

> Yeah I think so although I don't know enough about it to know for sure.
> I'm hoping to come up with something rough and then get a little help from
> people that know better.
>
> On Sunday, February 8, 2015 at 5:24:28 PM UTC-8, Curtis Maloney wrote:
>>
>> Certainly sounds useful, and the research seems to suggest all (most?) of
>> the major backends support it.
>>
>> --
>> C
>>
>>
>> On 9 February 2015 at 11:26, Bob Remeika  wrote:
>>
>>> Hi,
>>>
>>> I'm new to django and python in general but I've been a programmer for a
>>> while now.
>>>
>>> I was interested in trying to contribute to django in order to learn how
>>> to navigate the internals a little better and I had my eye on this ticket
>>> because I might actually need this functionality.
>>>
>>> https://code.djangoproject.com/ticket/10088
>>>
>>> Can anybody tell me what the status is on this?  Looks like it's wide
>>> open and a patch would be welcome assuming that it's not utter crap :)
>>>
>>> Thanks,
>>> Bob
>>>
>>> --
>>> 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/4365af12-ce4d-4117-944a-
>>> 472b5d7c1e1a%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/b58add74-7dd8-4780-8c12-bc200e781f13%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/CAG_XiSDhiLMqxUSSRysB7j3fFbH0Q%2BNpJ5JQCheDtsBiYaLmnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: new to django... looking to contribute to learn more

[Bob Remeika]

Yeah I think so although I don't know enough about it to know for sure. 
 I'm hoping to come up with something rough and then get a little help from 
people that know better.

On Sunday, February 8, 2015 at 5:24:28 PM UTC-8, Curtis Maloney wrote:
>
> Certainly sounds useful, and the research seems to suggest all (most?) of 
> the major backends support it.
>
> --
> C
>
>
> On 9 February 2015 at 11:26, Bob Remeika 
> > wrote:
>
>> Hi,
>>
>> I'm new to django and python in general but I've been a programmer for a 
>> while now.
>>
>> I was interested in trying to contribute to django in order to learn how 
>> to navigate the internals a little better and I had my eye on this ticket 
>> because I might actually need this functionality.
>>
>> https://code.djangoproject.com/ticket/10088
>>
>> Can anybody tell me what the status is on this?  Looks like it's wide 
>> open and a patch would be welcome assuming that it's not utter crap :)
>>
>> Thanks,
>> Bob
>>
>> -- 
>> 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/4365af12-ce4d-4117-944a-472b5d7c1e1a%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/b58add74-7dd8-4780-8c12-bc200e781f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: makemigrations caching prior migrations after deletion

[Yo-Yo Ma]

Sorry for the belated reply, Andrew and Curtis.

You're both right that the "bug" was just a case of makemigrations 
resolving dependency issues and my misunderstanding of that fact.

To test whether this was a bug or just makemigrations splitting up the 
migration, I had created a separate app with the exact same model as the 
supposedly offending app, and this time it didn't result in 2 migrations, 
so I thought I had empirically proven that this was some sort of pycache 
related bug... Afterword, I realized that this was because I had created 
the dependency's 0001 migration first, which of course then allowed 
makemigrations to simply add that 0001 migration as a dependency.


Michael


On Sunday, February 8, 2015 at 7:05:00 PM UTC-5, Andrew Godwin wrote:
>
> Indeed, Django can make many migrations for an initial set if it needs 
> them to de-circularise dependencies (e.g. two models with foreign keys 
> pointing at each other - it splits one of their FKs into a second 
> migration).
>
> Andrew
>
> On Sun, Feb 8, 2015 at 11:17 PM, Curtis Maloney <
> cur...@acommoncreative.com > wrote:
>
>> Could you provide details about what sort of field you added, please?
>>
>> I have seen cases where migrations will create two separate migrations 
>> for an initial.
>>
>> --
>> Curtis
>>
>> On 9 February 2015 at 10:11, Yo-Yo Ma 
>> > wrote:
>>
>>> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments 
>>> before this writing), I created a model with a "name" field, then created a 
>>> migration for it. Moments after, I added an "age" field to the model, 
>>> deleted the 0001_initial.py migration, deleted __pycache__ directories in 
>>> my entire project, deleted any *.py[cod] files in my project, then ran 
>>> makemigrations again (the goal being to create a fresh 0001 migration with 
>>> the latest fields again, since there is no SQLite3 database file (I 
>>> verified this as well)). When I do this, Django creates the same 0001 
>>> migration it did the first time, then creates a 0002 migration to add the 
>>> new field. Firstly, how is this even possible? Second, is this a known 
>>> issue in 1.8? I've never experienced this bug before, and it's always been 
>>> my M.O. on a new project to recreate a 0001 migration when I'm first 
>>> working on the models (to avoid having 30 migrations before the app is even 
>>> on a dev server).
>>>
>>> -- 
>>> 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/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%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-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/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%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 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/21d572d3-aa1d-4e16-99c1-894ae0cdc176%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: new to django... looking to contribute to learn more

[Curtis Maloney]

Certainly sounds useful, and the research seems to suggest all (most?) of
the major backends support it.

--
C


On 9 February 2015 at 11:26, Bob Remeika  wrote:

> Hi,
>
> I'm new to django and python in general but I've been a programmer for a
> while now.
>
> I was interested in trying to contribute to django in order to learn how
> to navigate the internals a little better and I had my eye on this ticket
> because I might actually need this functionality.
>
> https://code.djangoproject.com/ticket/10088
>
> Can anybody tell me what the status is on this?  Looks like it's wide open
> and a patch would be welcome assuming that it's not utter crap :)
>
> Thanks,
> Bob
>
> --
> 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/4365af12-ce4d-4117-944a-472b5d7c1e1a%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/CAG_XiSB5NWsYaiJFrHbo3KgBqynHad%3DwFFEK-%3Dpea3Lro%3DNJnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

new to django... looking to contribute to learn more

[Bob Remeika]

Hi,

I'm new to django and python in general but I've been a programmer for a 
while now.

I was interested in trying to contribute to django in order to learn how to 
navigate the internals a little better and I had my eye on this ticket 
because I might actually need this functionality.

https://code.djangoproject.com/ticket/10088

Can anybody tell me what the status is on this?  Looks like it's wide open 
and a patch would be welcome assuming that it's not utter crap :)

Thanks,
Bob

-- 
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/4365af12-ce4d-4117-944a-472b5d7c1e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: makemigrations caching prior migrations after deletion

[Andrew Godwin]

Indeed, Django can make many migrations for an initial set if it needs them
to de-circularise dependencies (e.g. two models with foreign keys pointing
at each other - it splits one of their FKs into a second migration).

Andrew

On Sun, Feb 8, 2015 at 11:17 PM, Curtis Maloney 
wrote:

> Could you provide details about what sort of field you added, please?
>
> I have seen cases where migrations will create two separate migrations for
> an initial.
>
> --
> Curtis
>
> On 9 February 2015 at 10:11, Yo-Yo Ma  wrote:
>
>> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments
>> before this writing), I created a model with a "name" field, then created a
>> migration for it. Moments after, I added an "age" field to the model,
>> deleted the 0001_initial.py migration, deleted __pycache__ directories in
>> my entire project, deleted any *.py[cod] files in my project, then ran
>> makemigrations again (the goal being to create a fresh 0001 migration with
>> the latest fields again, since there is no SQLite3 database file (I
>> verified this as well)). When I do this, Django creates the same 0001
>> migration it did the first time, then creates a 0002 migration to add the
>> new field. Firstly, how is this even possible? Second, is this a known
>> issue in 1.8? I've never experienced this bug before, and it's always been
>> my M.O. on a new project to recreate a 0001 migration when I'm first
>> working on the models (to avoid having 30 migrations before the app is even
>> on a dev server).
>>
>> --
>> 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/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%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/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%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 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/CAFwN1upLKUR4G2eKMCegBii72LWjB%3DvXoNe9VR-e1FC8SQWHWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding missing aggregate functions to contrib.postgres ?

[Russell Keith-Magee]

Hi Andriy,

If we're going down this path, I can't think of any reason we wouldn't
target ever available aggregate. It doesn't need to be all in one patch/PR
- in fact, I'd suggest that unless the implementations are particularly
intertwined, one patch per aggregate (or aggregate group - e.g., all the
bit_* aggregates) would be preferable.

The only other thing I'd flag is that if any of these aggregates are recent
additions (e.g., added in Postgres 9), the failure mode for earlier
versions should be relatively clean.

Yours,
Russ Magee %-)

On Sun, Feb 8, 2015 at 9:27 AM, Andriy Sokolovskiy (coldmind) <
sokand...@yandex.ru> wrote:

> OK, since ticket was market as accepted, should *all* aggregates functions
> from http://www.postgresql.org/docs/9.4/static/functions-aggregate.html
> be implemented ? I'm asking to prevent doing unnecessary work.
>
> воскресенье, 8 февраля 2015 г., 1:11:08 UTC+2 пользователь Andriy
> Sokolovskiy (coldmind) написал:
>
>> I opened a ticket for it.
>> https://code.djangoproject.com/ticket/24301
>>
>> суббота, 7 февраля 2015 г., 18:51:34 UTC+2 пользователь Michael Manfre
>> написал:
>>>
>>> It's reasonable to support backend specific aggregate functions. The
>>> database backend API contains 
>>> BaseDatabaseOperations.check_expression_support
>>> for this exact reason. Feel free to create the ticket.
>>>
>>> Regards,
>>> Michael Manfre
>>>
>>> On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
>>> soka...@yandex.ru> wrote:
>>>
 So, since django has contrib.postgres, maybe it would be reasonable to
 add postgres-specific aggregate functions to this module?
 If it is good idea, I'm gonna create ticket and implement this.

 --
 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/2d3b2bd2-3bce-4e40-8383-
 ef5ca328bc26%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/38e08166-a475-4214-8055-e81eeb452c85%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/CAJxq84_9fJnaePpNBaqRbUsmLmybwLtcwvTJ%3Dq87tBSSXmd2kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug: makemigrations caching prior migrations after deletion

[Curtis Maloney]

Could you provide details about what sort of field you added, please?

I have seen cases where migrations will create two separate migrations for
an initial.

--
Curtis

On 9 February 2015 at 10:11, Yo-Yo Ma  wrote:

> Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before
> this writing), I created a model with a "name" field, then created a
> migration for it. Moments after, I added an "age" field to the model,
> deleted the 0001_initial.py migration, deleted __pycache__ directories in
> my entire project, deleted any *.py[cod] files in my project, then ran
> makemigrations again (the goal being to create a fresh 0001 migration with
> the latest fields again, since there is no SQLite3 database file (I
> verified this as well)). When I do this, Django creates the same 0001
> migration it did the first time, then creates a 0002 migration to add the
> new field. Firstly, how is this even possible? Second, is this a known
> issue in 1.8? I've never experienced this bug before, and it's always been
> my M.O. on a new project to recreate a 0001 migration when I'm first
> working on the models (to avoid having 30 migrations before the app is even
> on a dev server).
>
> --
> 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/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%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/CAG_XiSD%3DG4tR6fE4aF6xdgdEX6%3D0gRRCTW8%3DyiS8g9KBrBz7pA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Possible bug: makemigrations caching prior migrations after deletion

[Yo-Yo Ma]

Using Python 3.4.2 and Django @stable/1.8.x (installed just moments before 
this writing), I created a model with a "name" field, then created a 
migration for it. Moments after, I added an "age" field to the model, 
deleted the 0001_initial.py migration, deleted __pycache__ directories in 
my entire project, deleted any *.py[cod] files in my project, then ran 
makemigrations again (the goal being to create a fresh 0001 migration with 
the latest fields again, since there is no SQLite3 database file (I 
verified this as well)). When I do this, Django creates the same 0001 
migration it did the first time, then creates a 0002 migration to add the 
new field. Firstly, how is this even possible? Second, is this a known 
issue in 1.8? I've never experienced this bug before, and it's always been 
my M.O. on a new project to recreate a 0001 migration when I'm first 
working on the models (to avoid having 30 migrations before the app is even 
on a dev server).

-- 
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/bfb1f2cd-b2be-4a16-a882-ecc6695865c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Allow shadowing of abstract fields

[Marten Kenbeek]

The general reaction seems to be a yes if we can work out the kinks, so I 
went ahead and created a ticket: https://code.djangoproject.com/ticket/24305

@Aron That's a good question. One option would be to lock certain fields, 
so that they can't be changed if they are an integral part of the model. 
That would be a simple solution, but that won't help for existing code that 
doesn't lock the fields. It won't break existing code, but it won't protect 
for errors either. The opt-in version (i.e. an 'unlock' attribute) would 
lock many fields which would otherwise be completely safe to overwrite. 

Another option would be more elaborate "requirements" for a manager or some 
methods, i.e. allow the manager to specify the necessary class of a certain 
field or a minimum length. If the modeldoesn't meet the requirements, the 
manager or some of the methods will not be inherited. While it allows for 
more control, this option would greatly increase the complexity of the 
patch and requires more from the developers of custom managers. It can also 
cause issues when the requirements aren't up-to-date with the manager's 
methods. 

We could also say that it is the users responsibility and don't provide 
special protection, in line with the fields themselves, but I guess that 
this would generally be more problematic for custom managers. It can also 
cause silent bugs when the manager's methods don't work as intended but 
won't raise an exception either, which is not a good idea imho. 

I think the locking approach would be the easiest and most pragmatic 
method. I think it's still - in part - the users responsibility to confirm 
that a field can be overridden. The Django documentation could, where 
applicable, document the requirements on fields that can be overridden, 
i.e. that an AbstractUser's username must be a CharField (which isn't 
necessarily true, just an example). 

@Loïc The bases are indeed traversed in the reversed order. 

Op zondag 8 februari 2015 08:19:57 UTC+1 schreef Loïc Bistuer:
>
> That's what we've done in Django 1.7 for Form/ModelForm (#19617, #8620), 
> and I completely agree that it should be possible to shadow fields from 
> abstract models. The docs even suggest that this may be possible in the 
> future; quoting the relevant section: "this [shadowing] is not permitted 
> for attributes that are Field instances (at least, not at the moment)." 
>
> For consistency with forms - and because we've put a great deal of 
> thinking into it - the implementation should be: you can shadow a field 
> with another field, or you can remove a field using None as a sentinel 
> value (see #22510 for more details). 
>
> I believe we have a safety net in the form of migrations, if you 
> accidentally shadow a field, migrations will pick it up, so it's unlikely 
> to go unnoticed. 
>
> I'd be quite happy to shepherd this patch. 
>
> Unit tests should cover those scenarios: 
>
> - An abstract model redefines or removes some fields from a parent 
> abstract model. 
> - A concrete model redefines or removes some fields from a parent abstract 
> model. 
> - Ensure that the standard MRO resolution applies when you do 
> Concrete(AbstractA, AbstractB) with AbstractA redefining a field from 
> AbstractB. 
>
> The last case may be tricky because if I remember well ModelBase iterates 
> through the MRO in the wrong direction (i.e. bases should be iterated over 
> in reverse). 
>
> We also need some tests to show how migrations behave. 
>
> -- 
> Loïc 
>
> > On Feb 7, 2015, at 09:33, Marten Kenbeek  > wrote: 
> > 
> > Hi Russ, 
> > 
> > I can see your point on accidentally overriding fields, though I'm not 
> sure I agree. In any other case, such as normal attributes and methods, 
> there is no safety net for overriding attributes either. Any model that 
> would be affected by this change would also raise an error on import 
> without the patch, so existing functional code won't be affected. On the 
> other hand, a new parameter for the field wouldn't be that much of a hassle 
> to implement or work with. I'd be interested to hear what others think 
> about this. 
> > 
> > There are more than a few questions on stack overflow that expect this 
> behaviour, even if the docs specifically mention that it won't work. If 
> users intuitively try to override fields in this manner, I think it would 
> be reasonable to allow this without any explicit arguments. 
> > 
> > We can always restrict what you can override, at least as the default 
> behaviour, e.g. so that you can only use subclasses of the original field. 
> That would make code that depends on the abstract field less prone to bugs, 
> though subtle bugs can still happen if you e.g. override the max length of 
> a field. 
> > 
> > This was indeed just a proof-of-concept. That remark was meant more like 
> "it doesn't appear to break everything". 
> > 
> > Marten 
> > 
> > Op vrijdag 6 februari 2015 23:48:55 UTC+1 schreef Marten Kenbeek: 
> > Hey, 
> > 
> > While 

ValidationError output of SafeData

[Andrew Pinkham]

Hi,
I mentioned on the Django User Mailing List that the interaction of 
ValidationError, mark_safe, and ugettext was not what I expected.

https://groups.google.com/d/topic/django-users/Soik095MTaI/discussion

Succinctly, the two versions of clean_slug below behave differently, when they 
should not.

# results in  being printed for user
def clean_slug(self):
new_slug = self.cleaned_data['slug'].lower()
if new_slug == 'invalid_value':
raise ValidationError(
# _ is ugettext
mark_safe(_('SlugField may not be '
'"%(slug_value)s" '
'for URL reasons.')),
params={
'slug_value':
mark_safe('invalid_value')})
return new_slug

# results in  being valid HTML elements
def clean_slug(self):
new_slug = self.cleaned_data['slug'].lower()
if new_slug == 'invalid_value':
raise ValidationError(
# _ is ugettext
mark_safe(_('SlugField may not be '
'"invalid_value" '
'for URL reasons.')))
return new_slug 

The problem behavior is caused by the way ValidationError outputs its text; 
ValidationError behaves differently depending on whether params are used, which 
seems undesirable. We can demonstrate this in the Django shell (1.7.4).

>>> from django.core.exceptions import ValidationError
>>> from django.utils.safestring import mark_safe, SafeData
>>> from django.utils.six import text_type
>>> isinstance(mark_safe('hello'), SafeData)
True

When the ValidationError message is SafeData, the output of the ValidationError 
is also SafeData.

>>> ve = ValidationError('this is static')
>>> isinstance(list(ve)[0], text_type)
True
>>> ve = ValidationError(mark_safe('this is safe'))
>>> isinstance(list(ve)[0], SafeData)
True

... unless we use the params feature of the exception, as the documentation 
tells developers to.

>>> ve = ValidationError(mark_safe('%(r)s'), params={'r': 'replaced'})
>>> isinstance(list(ve)[0], SafeData)
False
>>> ve = ValidationError(mark_safe('%(r)s'), params={'r': 
mark_safe('replaced')})
>>> isinstance(list(ve)[0], SafeData)
False

The difference in behavior depending on whether params is passed should not 
happen.

I can see how in the first instance above---where the message is SafeData but 
the params values aren't---it is desirable to return text instead of SafeData 
from a security standpoint. However, in the second case, when both the message 
and the params are SafeData, it seems counter-intuitive to return text.

| message | params | output |
|-|||
| text| none   | text   |
| safe| none   | safe   |
| text| text   | text   |
| safe| text   | text   |
| text| safe   | text   |
| safe| safe   | safe   | <-- the problem: currently outputs text

The issues stems from ValidationError.__iter__(). In `add_error` of form 
validation, ValidationErrors are added on with the following:

# django/forms/forms.py: line 353
self._errors[field].extend(error_list)

This code results in a call to ValidationError.__iter__(),

# django/core/exceptions.py: line 151
def __iter__(self):
if hasattr(self, 'error_dict'):
for field, errors in self.error_dict.items():
yield field, list(ValidationError(errors))
else:
for error in self.error_list:
message = error.message
if error.params:
message %= error.params
yield force_text(message)

Turns out, __mod__ on SafeText is not defined, meaning the code `message %= 
error.params` always transforms SafeText to text.

>>> isinstance(mark_safe('hello %(r)s'), SafeData)
True
>>> isinstance(mark_safe('hello %(r)s') % {'r': 'boo'}, SafeData)
False
>>> isinstance(mark_safe('hello %(r)s') % {'r': mark_safe('boo')}, SafeData)
False

I can thus think of two ways to solve this:

1. Modify ValidationError.__iter__() to account for SafeText with params.
2. add __mod__() to SafeText

Given that ugettext (or rather, do_translate() in 
django/utils/translation/trans_real.py) takes the first approach, I've created 
a branch in my fork of Django to do just that.

https://github.com/jambonrose/django/commit/61612f38aa68efcb5038f51305359b25485e2f48

My djangocore-box isn't working quite the way it should (postgres tests will 
not run on master), but all the tests appear to run correctly on 
runtests2.7-sqlite and runtests3.3-sqlite.

With that said: while I think there is a problem in the difference in behavior, 
I'm not sure my solution is the best. More simply: is the following behavior 
table actually what we want?

| message | params | output |
|-|||
| text| none   | text   |
| safe| no