Re: Two proposals for the Django Code of Conduct.

[Stephen Burrows]

Benjamin,

Out of your three links only the 3rd describes an actual harassment
> occurring at a Django-related event.


Actually, even the third link doesn't describe harassment occuring at a
Django-related event. It described harassment by a Django community member
at a non-Django event. And it describes an organizer flailing to know what
to do because they *didn't* have a policy. I'm a little confused how the
takeaway is "everything about that was fine" rather than "they should maybe
have had a policy". I will certainly agree that it was better than the
alternative, which would have been the organizer ignoring or dismissing her
concerns.

The other two links do talk about how exceptional DjangoCon is. And *part
of that* was that DjangoCon has an explicit code of conduct. So again, I
feel like you've missed the point. Codes of conduct do work.

By my statement "stop just talking about it and show us what that would
look like" I mean that you should write down the actual *text* of the
"affirmative policy" that you keep talking about. Write down the policy. In
detail. So that we can actually review what you think would be good. It's
fine to talk about your principles, and I don't necessarily disagree with
an affirmative policy, but right now *all* I'm getting from you is
principles. So again, please stop just talking about it and show us what it
would look like. As in, again, to be entirely explicit, write the policy
you would like to see so that we can read it.

This is particularly important if you actually want constructive feedback.
I can't give you feedback on something I can't see.

And please keep in mind that you are also motivated by good intentions, and
we all know which road is paved with those. In other words, good intentions
are not enough on any side of any argument.

Best,
Stephen

On Tue, Sep 9, 2014 at 11:47 AM, Alex Gaynor  wrote:

> When Jacob and I originally drafted the CoC, we specifically included an
> enumeration of some disallowed behaviors on the recommendation of the Ada
> Initiative -- it was their view that the list helped to minimize rules
> lawyering, whereby someone attempts to explain how they could not have
> known their behavior was disallowed.
>
> On reflection, I completely agree with their reasoning and am very glad we
> included it.
>
> Alex
>
>
> On Tue, Sep 9, 2014 at 11:43 AM, barbara.shaurette <
> barbara.shaure...@gmail.com> wrote:
>
>> As someone who has been the target of harassment at conferences (I've
>> been lucky, only minor incidents for me, although the same can't be said
>> for other of my female colleagues), I prefer explicit over implicit. If
>> someone is a harasser outside the community, I won't feel safe encountering
>> them in a conference setting either.
>>
>> That said, I trust the discretion of the core team and the DSF membership
>> and I'll be interested to see how they decide on the matter.
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/9f89cb24-f572-444d-9723-386eb93e495a%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFRnB2XfgpLy-zrb%2BSF%3D2Cz9KzErEWANYmtwmDCLn1xb8wS8yQ%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" 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 

Re: Two proposals for the Django Code of Conduct.

[Stephen Burrows]

Benjamin,

I believe there have been serious issues with harassment of women
specifically at previous DjangoCons (though there may not be mention of it
on the mailing lists.) It has definitely been a major issue at other tech
conferences and tech meetups. That was a major factor in the recent push in
the tech world to have better anti-harassment / code of conduct policies.
See also: http://geekfeminism.wikia.com/wiki/Timeline_of_incidents (and the
rest of the wiki, really).

Here is a short selection of other links that talk about this issue, with
various relations to Django / DjangoCon specifically.

http://geekfeminism.org/2013/08/15/that-time-i-wasnt-harassed-at-a-conference/
http://www.caktusgroup.com/blog/2012/05/24/narrowing-gender-gap-open-source-community/
http://juliaelman.com/blog/2012/jun/3/lets-get-little-louder/

I could just keep going, but I don't want to overwhelm people (slash you)
with too many links. If you want more, you can use google.

If you think a policy like this doesn't need to exist, you are IMO,
frankly, very wrong. But if you think it just needs to be written
differently, stop talking about it and show us what that would look like!

--Stephen

On Tue, Sep 9, 2014 at 9:33 AM, Kevin Daum  wrote:

> I'm going to attempt to reach out to some folks who I think might be more
> likely than us to benefit from a code of conduct and ask if they have
> anything to add. I'm not mounting a public campaign, I just think we're
> missing some important perspectives.
>
> On Tuesday, September 9, 2014 3:15:10 AM UTC-4, Robert Grant wrote:
>>
>> Good email. This one won't be that good.
>>
>> Boiling my verbose email down to two sentences:
>>
>> We seem to already have a private group of people who make decisions in
>> secret and pronounce a verdict on issues, and who can to a large extent
>> control the community. If this is the case, and they already have total
>> control should they choose to exercise it, a Django ASBO won't give any
>> extra power over - and thus protection against - griefers/bullies/whatever.
>>
>> Just to hedge my bets, if the group does decide to create the ASBO, could
>> it be called the Anti-Social Django Act?
>>
>> On Tue, Sep 9, 2014 at 7:33 AM, Benjamin Scherrey 
>> wrote:
>>
>>> Hi Kevin,
>>>
>>>And thanx for responding to my question about the need for such a
>>> policy with Django. Last night, as I had not yet had a response from anyone
>>> about this question I searched the archives of both django groups looking
>>> for any events or circumstances in which the code of conduct was invoked as
>>> I had no personal recollection of any such thing. I found some innocuous
>>> reference in the django-users group (wrongly suggesting that this coming
>>> policy was going to increase female participation) and in
>>> django-developers, one actual circumstance where its use was threatened -
>>> not surprisingly as part of the one example you provided that actually has
>>> anything to do at all with the Django community. Sadly, it's invocation was
>>> precisely used in the manner that I had feared - to stifle debate and
>>> threaten a person who was making valid and reasonable arguments (no doubt
>>> in the middle of a flame war but he/she wasn't the flamer). When I saw the
>>> name of the person who invoked the code of conduct I was even more
>>> disappointed as it was someone that I otherwise have a profound respect for.
>>>
>>> Other than this I was not surprised to see zero evidence for the
>>> need for such a policy as there don't seem to be any threatening events of
>>> the like that your email raises. These problems may exist elsewhere but not
>>> amongst the general django community that I've ever seen.
>>>
>>> Understand my background. I own a software development company that
>>> was a VERY early adopter of Django way before the 1.0 days. I expect I was
>>> certainly one of the first thousand developers to use Django in a real-life
>>> situation once it got outside of the newspaper where it was created. My
>>> company is one of the first to build commercial systems for clients on top
>>> of Django. My staff even has a few little commits into the django code base
>>> over the years, although minor, but we were proud nonetheless to be able to
>>> contribute in some small way. I've attended my share of PyCons (prior to
>>> the invention of DjangoCon which I hope to attend one day) and have always
>>> found the community very open and inclusive of all types. This is a Good
>>> Thing (TM). I've even sent 5 staff to the event, four of which happened to
>>> be women. My team now consists of 34+ people, all but two of which are in a
>>> technical capacity. WE are geeks who seek out other geeks who want to be
>>> appreciated solely based on merit. We happen to have about a 40% female
>>> colleague share and explicitly do NOT have a diversity policy (nor will we
>>> ever have an HR department but that's another story). I 

Re: Two proposals for the Django Code of Conduct.

[Stephen Burrows]

If you think you could do it better, maybe you should submit your own
version for consideration. I assume that's how the process works.


On Mon, Sep 8, 2014 at 11:20 AM, Benjamin Scherrey 
wrote:

> Daniele,
>
> You're reading me completely wrong. I am not being sarcastic at all.
> I'm pointing out the absurdity that one style of "code of conduct"
> inevitably leads to versus another affirmative style which could actually
> serve it's intended purpose. I'm not against any code - I'm quite
> specifically supportive of one style and very aware and concerned about the
> ramifications of the other. I don't know how much more clear I can make the
> point than I already have.
>
> Thus far, however, your only response to my actual concern is
> assurances that people will "do the right thing and be reasonable". Forgive
> me if that holds absolutely no water with me because, even if I were to
> trust you personally, you have no power to enforce such an assurance. But I
> understand that's the best you can do because that is the best that can
> ever be done with this type of thing. So the only responsible action is
> don't go there. If you're going to make a policy that is completely open to
> any individual's interpretation then you've actually set back the community
> and have laid the foundation to harm to the very thing you're trying to
> protect.
>
> You keep using the term "known harasser" but attempts to codify what
> that is exactly are impossible via lists of "forbidden speech/actions". I
> welcome evidence to the contrary but I'm fairly experienced in such matters
> and don't anticipate any forthcoming. In some circles I might be a bit more
> forgiving for willfully ignoring these facts. But this is a programming
> group for goodness sakes! We know how to be specific about things and the
> dangers of opening up things to ambiguity. We can do better. So given this,
> why not just go with an affirmative policy stating how people should
> conduct themselves and demonstrate good intentions without the need to
> codify "evil things"? I think it accomplishes what you want to do and, best
> of all, could actually work!
>
> -- Ben Scherrey
>
> On Mon, Sep 8, 2014 at 6:56 PM, Daniele Procida  wrote:
>
>> On Mon, Sep 8, 2014, Benjamin Scherrey  wrote:
>>
>> >I thought I made my objections pretty clear in my original email but I'll
>> >attempt to be more pedantic about it now. The specific language in the PR
>> >86 is:
>> >
>> >"In addition, violations of this code outside these spaces may affect a
>> >person's ability to participate within them." for both faq.html and
>> >index.html.
>> >
>> >I disagree with your assertion "that only makes explicit something that
>> was
>> >already the case" because that's a) not how I read it and b) completely
>> >impossible to reasonably enforce or expect.
>>
>> I can assure you that if we became aware of someone's problematic
>> behaviour then depending on the behaviour we could do anything from keeping
>> a careful eye on the individual to - in extreme cases - banning them from
>> participation.
>>
>> "Violations of this code outside these spaces may affect a person's
>> ability to participate within them" is correct. It doesn't mean that action
>> will be taken, but that it may be.
>>
>> That's already the case. If a known harrasser subscribes starts posting
>> to one of our email lists, we might have a quiet word with them, just for
>> example.
>>
>> >I hope that what is occurring is
>> >simply a matter of "I don't think it means what you think it means" but
>> >what you're really saying here is that all people on this planet must
>> >comply with our "code of conduct" at all times in all places or risk
>> being
>> >removed from our community - right after, mind you ironically, claiming
>> to
>> >support an encourage the participation of all individuals.
>>
>> Being removed from the community would be the last, not the first, course
>> of action.
>>
>> >So what is this
>> >code of conduct that we're imposing on all of humanity for the salvation
>> of
>> >the world?
>>
>> You've had your points answered twice already, politely both times. If
>> you want to make sarcastic remarks for your own amusement, don't expect any
>> more replies.
>>
>> Daniele
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/20140908115639.2110009050%40mail.wservices.ch
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Chief Systems Architect Proteus 

Re: Two proposals for the Django Code of Conduct.

[Stephen Burrows]

Turns out there *is* a document detailing enforcement policies and it
*does* involve a range of possible responses to violations.

https://github.com/django/djangoproject.com/blob/master/templates/conduct/enforcement.html
https://www.djangoproject.com/conduct/enforcement-manual/


On Mon, Sep 8, 2014 at 12:30 AM, Stephen Burrows <
stephen.r.burr...@gmail.com> wrote:

> Ben,
>
> Just to clarify, it sounds like what you're saying is the following: If
> there were a member of the django community who (may this never be the
> case) was harassing members of the django community, but limited their
> harassment to non-django-specific forums, you would want it to not affect
> their participation in django spaces.
>
> Is that correct? If so, is that a blanket statement or does it depend in
> your mind what exactly they've done? For example, what if they had a single
> hateful tweet? What if they had five? What if they orchestrated a
> harassment campaign that drove someone from their home?
>
> Where would you draw the line?
>
> I would also like to point out that the code of conduct doesn't seem to
> contain any statements about how it's enforced. Generally speaking,
> policies like this operate with a certain number of warnings, followed by
> escalation if that doesn't stick - except in extreme cases. It even says
> explicitly *in* the policy:
>
> Don’t forget that it is human to err and blaming each other doesn’t get us
>> anywhere, rather offer to help resolving issues and to help learn from
>> mistakes.
>
>
> I understand that you're concerned about the application of the policy,
> but it seems like you're (perhaps unintentionally) exaggerating the scope
> and purpose of the policy to support your point.
>
> --Stephen
>
>
> On Mon, Sep 8, 2014 at 12:16 AM, Benjamin Scherrey <proteus...@gmail.com>
> wrote:
>
>> I thought I made my objections pretty clear in my original email but I'll
>> attempt to be more pedantic about it now. The specific language in the PR
>> 86 is:
>>
>> "In addition, violations of this code outside these spaces may affect a
>> person's ability to participate within them." for both faq.html and
>> index.html.
>>
>> I disagree with your assertion "that only makes explicit something that
>> was already the case" because that's a) not how I read it and b) completely
>> impossible to reasonably enforce or expect. I hope that what is occurring is
>> simply a matter of "I don't think it means what you think it means" but
>> what you're really saying here is that all people on this planet must
>> comply with our "code of conduct" at all times in all places or risk being
>> removed from our community - right after, mind you ironically, claiming to
>> support an encourage the participation of all individuals. So what is this
>> code of conduct that we're imposing on all of humanity for the salvation of
>> the world? Fortunately there is, literally, a list:
>>
>>   
>> Violent threats or language directed against another person.
>> Sexist, racist, or otherwise discriminatory jokes and
>> language.
>> Posting sexually explicit or violent material.
>> Posting (or threatening to post) other people's personally
>> identifying information ("doxing").
>> Personal insults, especially those using racist or sexist
>> terms.
>> Unwelcome sexual attention.
>> Advocating for, or encouraging, any of the above behavior.
>> Repeated harassment of others. In general, if someone asks you to
>> stop, then stop.
>>   
>>
>> So lets see... anyone who has done any of the following completely
>> outside the context of the Django community or forums is now not welcome to
>> participate:
>>
>> 1) Ever threatened to or actually spank their children.
>> 2) Ever used violence or threat there-of to defend another person from
>> same.
>> 3) Ever posted a naked or somewhat explicit picture of themselves or
>> others in a private message to another person or in a forum, such as a
>> photo site like flickr.
>> 4) Dox'd a person who is clearly engaging in criminal activity under a
>> pretense of anonymity.
>> 5) Ever repeated a joke with sexual or racial content.
>> 6) Ever asked someone out or complemented another person on their looks
>> who didn't want it.
>> 7) Said it's ok for someone to do any of the above.
>> 8) Said or did it twice.
>>
>> Seriously?!?! This *is* really what you're saying. (BTW - I've done all
>> of the above at one time or another so ban me now.)
>>
>> Of course some of the

Re: Two proposals for the Django Code of Conduct.

[Stephen Burrows]

Ben,

Just to clarify, it sounds like what you're saying is the following: If
there were a member of the django community who (may this never be the
case) was harassing members of the django community, but limited their
harassment to non-django-specific forums, you would want it to not affect
their participation in django spaces.

Is that correct? If so, is that a blanket statement or does it depend in
your mind what exactly they've done? For example, what if they had a single
hateful tweet? What if they had five? What if they orchestrated a
harassment campaign that drove someone from their home?

Where would you draw the line?

I would also like to point out that the code of conduct doesn't seem to
contain any statements about how it's enforced. Generally speaking,
policies like this operate with a certain number of warnings, followed by
escalation if that doesn't stick - except in extreme cases. It even says
explicitly *in* the policy:

Don’t forget that it is human to err and blaming each other doesn’t get us
> anywhere, rather offer to help resolving issues and to help learn from
> mistakes.


I understand that you're concerned about the application of the policy, but
it seems like you're (perhaps unintentionally) exaggerating the scope and
purpose of the policy to support your point.

--Stephen


On Mon, Sep 8, 2014 at 12:16 AM, Benjamin Scherrey 
wrote:

> I thought I made my objections pretty clear in my original email but I'll
> attempt to be more pedantic about it now. The specific language in the PR
> 86 is:
>
> "In addition, violations of this code outside these spaces may affect a
> person's ability to participate within them." for both faq.html and
> index.html.
>
> I disagree with your assertion "that only makes explicit something that
> was already the case" because that's a) not how I read it and b) completely
> impossible to reasonably enforce or expect. I hope that what is occurring is
> simply a matter of "I don't think it means what you think it means" but
> what you're really saying here is that all people on this planet must
> comply with our "code of conduct" at all times in all places or risk being
> removed from our community - right after, mind you ironically, claiming to
> support an encourage the participation of all individuals. So what is this
> code of conduct that we're imposing on all of humanity for the salvation of
> the world? Fortunately there is, literally, a list:
>
>   
> Violent threats or language directed against another person.
> Sexist, racist, or otherwise discriminatory jokes and
> language.
> Posting sexually explicit or violent material.
> Posting (or threatening to post) other people's personally
> identifying information ("doxing").
> Personal insults, especially those using racist or sexist
> terms.
> Unwelcome sexual attention.
> Advocating for, or encouraging, any of the above behavior.
> Repeated harassment of others. In general, if someone asks you to
> stop, then stop.
>   
>
> So lets see... anyone who has done any of the following completely outside
> the context of the Django community or forums is now not welcome to
> participate:
>
> 1) Ever threatened to or actually spank their children.
> 2) Ever used violence or threat there-of to defend another person from
> same.
> 3) Ever posted a naked or somewhat explicit picture of themselves or
> others in a private message to another person or in a forum, such as a
> photo site like flickr.
> 4) Dox'd a person who is clearly engaging in criminal activity under a
> pretense of anonymity.
> 5) Ever repeated a joke with sexual or racial content.
> 6) Ever asked someone out or complemented another person on their looks
> who didn't want it.
> 7) Said it's ok for someone to do any of the above.
> 8) Said or did it twice.
>
> Seriously?!?! This *is* really what you're saying. (BTW - I've done all of
> the above at one time or another so ban me now.)
>
> Of course some of these (but not all - and it depends a lot about whom)
> may seem outrageous but they are true to the letter of the code of conduct.
> I agree these things probably don't belong in the context of a Django
> discussion or group but I do not believe you can enforce elimination this
> conduct outside of same. And - then there's just the ability to agree to
> disagree. One can very credibly argue that many religions or political
> philosophies are racist, sexist, etc. Are all practicing members of same
> now banned from participation in Django? This RP language says yes.
>
> Now that I have, again, been responsive to your dismissal of my
> objections, please do me the courtesy of re-reading my original (and this)
> email and attempt to be responsive to it's content.
>
> thank you,
>
>   -- Ben Scherrey
>
> On Mon, Sep 8, 2014 at 3:04 AM, Daniele Procida  wrote:
>
>> On Mon, Sep 8, 2014, Benjamin Scherrey  wrote:
>>
>> >Nothing you've written 

1.7 release?

[Stephen Burrows]

It's been a while since I've heard anything about the 1.7 release - but it
looks like there aren't any release blockers left
.
And there weren't any the last time I checked either. What's the status? Is
it just waiting for final review? Is it just waiting for DjangoCon? Is
there anything that community members can do?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMv_%2B6VHdaQP%2BDqb8h%2Bo_AtL-e9-kyoOS5%2BVhODdY3J%3DDDFuXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Tests of contrib apps

[Stephen Burrows]

The tests are nested whether they're in the core tests or in contrib. 
Philosophically this is more a question of coding at a distance. Putting 
the tests in /tests makes it less obvious which app they actually belong 
to. Additionally, I'd see the fact that it would be impossible to use 
manage.py test as a detriment rather than an advantage. If people want to 
not run the tests for an app, they can always just list the apps they do 
want to test. Also, django-nose is pretty useful for handling test 
discovery issues, if you're looking for a quick fix.

--Stephen

On Wednesday, March 20, 2013 2:26:33 AM UTC-7, Aymeric Augustin wrote:
>
> Hello, 
>
> Currently there are three locations for the tests of contrib apps: 
> - under tests/ — eg. admin 
> - inside the app — eg. auth 
> - both — eg. contenttypes 
>
> Following the modeltests / regressiontests merge, I propose to move all 
> contrib app tests under tests/. This has de following advantages: 
> - it makes them easier to discover and prevents accidental duplication 
> - they won't be run by './manage.py test' 
> - it'll dam up the stream of "if I change setting X then test Y in contrib 
> app Z fails" 
>
> I'm aware of the idea that contrib apps could include integration tests to 
> validate that they're properly used within projects, but I don't believe we 
> have any such tests currently. 
>
> What do you think? 
>
> -- 
> Aymeric. 
>
>
>
>

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

Re: first() and last(), earliest() and latest()

[Stephen Burrows]

So if I understand correctly, you want something that returns 0-or-1 
objects, without having to do try/except? (Or alternately, try: qs[:1][0] 
except IndexError.)

First of all, I don't understand why first/last are the names you've 
chosen. This isn't about getting the first object or the last object. It's 
about getting first/last or None. That behavior is inconsistent with the 
way that Django's ORM works. (Though granted, it wouldn't be the only 
internal inconsistency.) A name like get_or_none() would make more sense to 
me, but apparently that was vetoed in the previous thread.

Second, I don't understand what you expect to gain from adding these 
methods. Yes, I know you save a few lines of code. If it doesn't matter 
whether you get an object or not, you save three lines. If you have to take 
different paths, you only save one line. Essentially you're replacing this:

try:
 obj = Model.instance.order_by(...)[:1][0]
except IndexError:
 # Do something
else:
 # Do something else

With this:

obj = Model.instance.order_by(...).first()
if obj is None:
 # Do something
else:
 # Do something else

The gains don't seem to justify the means.

Third, this seems to be about replacing latest/earliest. Personally, I 
don't have much use for either method, since they can be replaced with the 
first snippet above without any trouble. If anything, I'd rather see 
latest/earliest removed from the API than add new methods that do 
essentially the same thing. What I might see being useful would be a method 
to reverse the ordering of a queryset - which it turns out already 
exists.

Fourth, the methods proposed don't seem to do anything beyond act as 
shortcuts. In contrast, get_or_create (which on the surface is a similar 
shortcut) also adds protection against database inconsistencies by manually 
handling transactions.

On Wednesday, February 27, 2013 5:34:16 PM UTC-5, Wim Feijen wrote:
>
> Hi all,
>
> We struggled to get a proper definition for a first() and last() method 
> vs. earliest() and latest() . I'd like to make one proposal. After that, I 
> really like your opinion on which syntax you prefer.
>
> First, let me give you a lenghty introduction. We discussed several use 
> cases on this mailing 
> list.
>  
> Then, I realized that:
>
> .filter(last_name__startswith='b').order_by('last_name').first()
> is an acceptable compromise for me to use in stead of:
> .first(last_name__startswith='b').order_by('last_name')
>
> Last weekend Aymeric explained to me that earliest can actually accomplish 
> the same:
> .filter(last_name__startswith='b').earliest('last_name')
>
> Then, I find "earliest" an inappropriate name, because it does not 
> describe functioning well.
>
> Therefore, my proposal is, if we are going to implement the earliest and 
> latest method, we should definitely rename them to: first and latest.
>
> After that, there is only one question left:
>
> Which style do you prefer?
>
> .filter(last_name__startswith='b').order_by('last_name').first()# 
> clear and long
> .first(last_name__startswith='b').order_by('last_name')# first method 
> has filter syntax.
> .filter(last_name__startswith='b').first('last_name')   # first method has 
> order_by syntax.
>
> So, what do you think?
>
> Best regards,
>
> Wim
>

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

Re: Ticket 19237

[Stephen Burrows]

... if we're concerned about strip_tags' ability to hit this kind of edge 
case, why are we using regex?

http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

Or more 
generally 
http://www.codinghorror.com/blog/2009/11/parsing-html-the-cthulhu-way.html.

On Saturday, November 17, 2012 1:01:33 AM UTC-8, Chris Khoo wrote:
>
> Hi
>
> I was wondering if one of the core developers could have a look at ticket 
> #19237 and progress it forward - 
> https://code.djangoproject.com/ticket/19237
>
> It basically makes django.utils.html.strip_tags a little smarter.
>
> Thanks
>
> Chris
>

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

Re: Django Admin Revamp - Any updates?

[Stephen Burrows]

There is a project to create a third-party django admin. It is currently 
moving slowly, but it does have basic admin functionality.

https://github.com/django-djam/django-djam
irc: Freenode/#django-djam (if you want to ping me about it.)

--Stephen

On Friday, November 16, 2012 7:41:05 AM UTC-8, Christian Bertschy wrote:
>
> Hi everyone
>
> At Divio we are working on a new look of the Django Admin for our 
> projects. To be clear, it's just the looks. I agree 100% with Idan that a 
> real revamp should consider not only the looks but also rethink the way the 
> admin works (and we all know that this is a huge difference :-)). 
>
> But in the meantime: https://github.com/divio/djangocms-admin-style
>
> It's still in beta, but feel free to use it or even better contribute to 
> it.
>
> Here are some screenshots:
> https://www.dropbox.com/sh/oicwr3g4wu9x1z1/VymKkK2FZM
>
> Have fun,
>
> Christian
>
>
> On Friday, April 27, 2012 1:06:06 AM UTC+2, Victor Hooi wrote:
>>
>> Hi,
>>
>> Is there any news on the Django Admin rewrite front?
>>
>> I remember around a year ago, there was quite a bit of talk on revamping 
>> the Django admin UI - I think Idan Gazit was heading that, right?
>>
>> Is that still on the Django roadmap? Any idea of whether it'll be in 1.5, 
>> 1.6, 1.7 etc?
>>
>> Cheers,
>> Victor
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/SeJ9gflYUnkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Add a "split" field to a model causes problems

[Stephen Burrows]

I've opened a ticket  to track 
this issue.

On Tuesday, October 23, 2012 3:52:10 AM UTC-7, Andrew Ingram wrote:
>
> Hi all,
>
> This one stung me today. Basically as part of an event (calendar) app, I 
> have functionality for splitting a series of events into two at a given 
> timestamp. The details aren't particularly relevant, but the key thing is 
> that I had a method called "split" on one of the models.
>
> This was working fine until I tried to add a ManyToManyField to the same 
> model, at which point it through a rather ugly error during initialisation 
> of the apps.
>
> django/db/models/fields/related.py line 56, in add_lazy_relation
>> app_label, model_name = relation.split(".")
>> TypeError: unbound method split() must be called with RecurringEvent 
>> instance as first argument (got str instance instead)
>
>
> Because I had no knowledge of the inner workings here, this error wasn't 
> helpful until pdb told me that `relation` was an instance of my model. The 
> issue is that in this point in the code, relation can either be a model or 
> a string 'app_label.model_name', so it's using the presence of a split 
> function to determine which it is, me having a split function on my model 
> breaks this check. Having a non-callable 'split' causes a similar problem, 
> just with a different exception.
>
> Long story short, adding a 'split'  method to my model caused the 
> inner-workings of Django to break, I think the documentation should provide 
> a list of attribute names that can't be added to a Django model without 
> breaking things, though this is the first time I've ever come across such a 
> problem so it might be a one-off.
>
> Regards,
> Andrew Ingram
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/EdVhEEdr74MJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

[Stephen Burrows]

Thanks, Florian. That clarifies things. I didn't realize collectstatic was 
using two backends, but it makes sense. And thanks for putting up with me 
not being up to speed on the IRC discussion.

On Tuesday, October 9, 2012 1:20:39 AM UTC-7, Florian Apolloner wrote:
>
> Hi Stephen,
>
> On Tuesday, October 9, 2012 7:28:43 AM UTC+2, Stephen Burrows wrote:
>>
>> I'm a little confused by the track the discussion took recently... my 
>> impression was that the solution would *not* be to change from 
>> last_modified to a checksum, or to add an additional checksum method. 
>> Instead, storage backeds could support a has_changed method, which could be 
>> overridden to provide last_modified checking *or* checksum comparisons - or 
>> any other method of checking whether a file has changed. This seems like a 
>> useful, easy-to-explain, very generic way to handle checking whether a file 
>> has changed.
>
>
> This would be one way to do it (we've also discussed that in IRC), but we 
> couldn't figure out any implementation that would actually be useable. To 
> make this work you'd need to have a function signature like "def 
> has_changed(file_name, other_thing)" whereas other_thing would be some 
> hash/modified_time whatever provided by the source storage. Now we are back 
> to the situation I described in my answer to Jeremy…
>
>  
>
>> And since what staticfiles actually cares about is whether the file has 
>> changed, it seems like it would make more 
>
> sense to use a method that checks whether the file has changed, rather 
>> than just checking the last modification date.
>
>
> Well staticfiles doesn't care, it's only collectstatic which cares to some 
> extend. So in my opinion the cleanest way (which means without coupling the 
> two needed storage backends together to strongly) is to provide your own 
> collectstatic command where you can do what you want with the checks (if 
> you have problems implementing that we'd happily move some code to extra 
> methods to make reusing collectstatic easier).
>  
>
>> Would I be correct in thinking that the main argument against this is API 
>> bloat, or is there something else that I'm not seeing?
>>
>
> I'd rather say: We don't see __any__ nice way to actually support 
> something which is generic enough the be useful. 
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/A7G6vLq58aYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

[Stephen Burrows]

I'm a little confused by the track the discussion took recently... my 
impression was that the solution would *not* be to change from 
last_modified to a checksum, or to add an additional checksum method. 
Instead, storage backeds could support a has_changed method, which could be 
overridden to provide last_modified checking *or* checksum comparisons - or 
any other method of checking whether a file has changed. This seems like a 
useful, easy-to-explain, very generic way to handle checking whether a file 
has changed. And since what staticfiles actually cares about is whether the 
file has changed, it seems like it would make more sense to use a method 
that checks whether the file has changed, rather than just checking the 
last modification date.

Would I be correct in thinking that the main argument against this is API 
bloat, or is there something else that I'm not seeing?

On Thursday, September 27, 2012 9:51:52 AM UTC-7, Dan Loewenherz wrote:
>
> Hey all!
>
> This is a feature request / proposal (one which I'm willing to build out, 
> given that I've already developed a solution for my own uploader).
>
> I run a consulting business that helps small startups build initial MVPs. 
> When the time ultimately comes to deciding how to store static assets, my 
> preference (as is that of many others) is to use Amazon S3, with Amazon 
> CloudFront acting as a CDN to the appropriate buckets. For the purposes of 
> this ticket, s/S3/your object storage of choice/g.
>
> Now, Django has an awesome mechanism for making sure static assets are up 
> on S3. With the appropriate static storage backend, running ./manage.py 
> collectstatic just searches through your static media folders and copies 
> the files.
>
> The problem I've run into is that collectstatic copies all files, 
> regardless of whether they already exist on the destination. Uploading 
> 5-10MB of files is pretty wasteful (and time consuming) when none of the 
> files have changed and no new files have been added.
>
> As I wrote in the trac ticket (https://code.djangoproject.com/ticket/19021), 
> my current solution was to write a management command that does essentially 
> the same thing that collectstatic does. But, there are a few differences. 
> Here's a rundown (copied straight from the trac ticket).
>
> I currently solve this problem by creating a file containing metadata of 
>> all the static media at the root of the destination. This file is a JSON 
>> object that contains file paths as keys and checksum as values. When an 
>> upload is started, the uploader checks to see if the file path exists as a 
>> key in the dictionary. If it does, it checks to see if the checksums have 
>> changed. If they haven't changed, the uploader skips the file. At the end 
>> of the upload, the checksum file is updated on the destination.
>
>
> I'll contribute the patch. I know there is not a lot of time before the 
> feature freeze, but I'm willing to make this happen if there's interest.
>
> If we don't want to change behavior, perhaps adding a flag such as 
> --skip-unchanged-files to the collectstatic command is the way to go?
>
> All the best,
> Dan
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/khLi3g_3z4EJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

[Stephen Burrows]

I use S3 as well, and I have seen cases where files get copied that I know 
don't need to be. That being said, it was never so slow that it was an 
issue for me. Is there clear evidence that this is something which can't be 
handled by the S3 backend due to an inadequate API on the django side?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/D9eemazwQUQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ModelForm enforces its version of save_m2m

[Stephen Burrows]

It's definitely possible for users to support commit=False. If you call 
form.save(commit=False), you can then store form.save_m2m in a temporary 
variable, define a new save_m2m function, and then call the old function 
from the new. Here's sort of an example: 
https://github.com/pculture/mirocommunity/blob/31688f2/localtv/user_profile/forms.py#L76.
 
Does it a little differently, but the same result.

--Stephen

On Tuesday, May 22, 2012 2:53:00 AM UTC-7, is_null wrote:
>
> Hello everybody, 
>
> Currently, Django ModelForm enforces it's local version of save_m2m: 
>
> https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76
>  
>
> As a result, users who want to overload save_m2m can not support 
> commit=False: 
> https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/contrib/generic_m2m.py#L50
>  
>
> Wouldn't it be great if users could overload save_m2m ? 
>
> If you agree, I volunteer to do the ticket and pull request. Else I'll 
> leave my hack in my app :( 
>
> Regards 
>

On Tuesday, May 22, 2012 2:53:00 AM UTC-7, is_null wrote:
>
> Hello everybody, 
>
> Currently, Django ModelForm enforces it's local version of save_m2m: 
>
> https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76
>  
>
> As a result, users who want to overload save_m2m can not support 
> commit=False: 
> https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/contrib/generic_m2m.py#L50
>  
>
> Wouldn't it be great if users could overload save_m2m ? 
>
> If you agree, I volunteer to do the ticket and pull request. Else I'll 
> leave my hack in my app :( 
>
> Regards 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/V9VRuLelOfEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Dogfood the new class-based views in contrib.syndication?

[Stephen Burrows]

I was recently working with django's syndication framework, and noticed 
that it felt clunky in a lot of ways. For example, I can only access the 
request and the kwargs for the function during the get_object method; if I 
want to do anything more complicated with them - for example, say I want to 
limit the items returned based on a tag that's in a GET parameter - there's 
not much that I can do. (I've chosen to return a dictionary from get_object 
containing the actual object and any variables that I want to have passed 
around to all the different methods.)

It seems like this would be a great place to dogfood the new CBVs; they 
could bring a lot of elegance to the framework. (For example, the whole 
'dynamic attribute' feature would be unnecessary.) This is obviously 
something that can be done as a third-party app first; I'm just curious 
whether this is something that (generally speaking) people would be 
interested in seeing. I tried checking the tracker and google for previous 
discussions about this, but didn't find anything.

--Stephen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ZCKJd55-p4kJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: upgrading the choices machinery for Django

[Stephen Burrows]

I generally like this idea, except for the implicit integer ids based
on declaration order. As people have said, it seems like just asking
for data corruption. I'd much rather see implicit character ids based
on the attribute name of the choice, analogous to django fields.

Will you be making this project available as a third-party app?

--Stephen

On Apr 4, 5:41 pm, Alex Ogier  wrote:
> On Wed, Apr 4, 2012 at 5:18 PM, Łukasz Langa  wrote:
> > Wiadomość napisana przez Daniel Greenfeld w dniu 4 kwi 2012, o godz. 22:48:
>
> > > On two occasions now I've had to do serious debugging on implementations
> > done by other people who used a technique not dissimilar to what Łukasz
> > proposes. In both cases, while the inheritance and better control
> > structures were nice, the issue was that if you give people enough rope to
> > hang themselves, they will.
>
> > Can you elaborate on that a bit? Even if the proposal is rejected in the
> > end, I might use your experience to at least make the rope less deadly.
>
> I imagine a big one is that without an explicit database representation for
> every item, it is easy to get out of sync with the real data you have. And
> when that happens, there isn't necessarily a good way of retrieving the
> meaning of old data: if some data in your database says that you are using
> license '302' but that index was implicitly auto-generated by the
> particular ordering of Choice() instantiations, then when the ordering
> changes you can lose track (and indexing based on an implicit ordering of
> class attributes definitely seems shaky to me).
>
> When I use enumerated fields, I generally make them VARCHAR(10) or so, and
> then use plain English, potentially abbreviated, for a database
> representation. That makes for reasonable code, "if self.license ==
> 'gpl_any':" looks very readable to me, and doesn't restrict you from
> altering display values for internationalization.
>
> It seems to me like this is really a documentation problem, where
> distilling the wisdom of developers like Adrian into a little best
> practices paragraph in the choices argument reference would go very far in
> making the awkwardness go away.
>
> Best,
> Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Stephen Burrows]

> Personally, I would like to be able to see a tag all at once (that is
> without scrolling), even though I might have to scroll to get to the
> start of it.  I believe this improves readability of the template. My
> specific use case is with include tags with long template paths and
> added context variables.

Most text editors let you enable line-wrapping... though this isn't as
"elegant" as multi-line tags, it would let you see everything without
scrolling.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Feature Request: Client side validation classes for forms

[Stephen Burrows]

The problem I've run into with client-side validation of django
projects is:

1) If you can't replicate every piece of validation the server does,
the user experience will be inconsistent, which is bad.
2) You can't replicate every piece of validation the server does.
Simple example: uniqueness checks. (Well, I suppose that technically
you could include the entire database table in the response and check
uniqueness of whatever field client-side, but I really hope that
sounds like a terrible idea to you.)

Ajax validation would be the way to go; ideally, you would be able to
do it on a per-field basis - but if there were a generic way of doing
it for a form, limiting that form to a subset of fields would be
trivial.

On Feb 6, 8:31 pm, Tai Lee  wrote:
> I found that Alex's `django-ajax-validation` works pretty well for
> this and I think it works the way you described. Perhaps it could be
> updated and included into Django core, if there is good support for
> it.
>
> https://github.com/alex/django-ajax-validation/
>
> Cheers.
> Tai.
>
> On Feb 4, 8:03 am, Adrian Holovaty  wrote:
>
>
>
>
>
>
>
> > On Fri, Feb 3, 2012 at 11:46 AM, Karthik Abinav
>
> >  wrote:
> > >   I was thinking about a feature that could be implemented. For common
> > > fields like username having only alphanumeric , or phone numbers having 
> > > only
> > > numbers, a client side validation need not be written every time.Instead 
> > > one
> > > could directly write something like,
>
> > > forms.CharField(validator = "usernamevalidation")
>
> > > in the forms definition and the client side validation for that field 
> > > would
> > > automatically be taken care of by the validator class. This will save a 
> > > lot
> > > of time while making large websites with lot of registration forms and in
> > > general be helpful to people who dont really know javascript and yet want
> > > some amount of frontend validation in place.
>
> > I like the idea of having a JavaScript version of form validation.
> > Basically we could make a view class that takes a Form object in
> > __init__() and returns JSON of the errors in a consistent way -- this
> > would be very easy to do. Then we could provide some standard
> > JavaScript to parse that JSON and add the error messages to the
> > appropriate fields in the form in a consistent way.
>
> > Good idea! It's a bit too late now to add it to Django 1.4, but I'd
> > like to implement this for the next version.
>
> > Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deprecate change pk + save behavior for 1.4

[Stephen Burrows]

I've often longed for a "read-only" concept in ModelForms. For
example, if I want the "site" field to always have a certain value
(i.e. the current site) but also want to enforce multiple-column
uniqueness (i.e. slug/site). I can write it myself, but it always
feels like I shouldn't have to. Probably since the admin already
provides that functionality.

Point being, that's something that, if it is implemented, should
probably be implemented separately from the pk stuff which is
currently being discussed.

Personally, I haven't had much use for natural primary keys since I
started using Django. (Though probably that's because it's so easy in
django to use the AutoField pk and because so many things expect
integer pks.) Are there a lot of people who use them?

--Stephen

On Dec 3, 7:58 pm, Anssi Kääriäinen  wrote:
> On Dec 3, 7:18 pm, Carl Meyer  wrote:
>
>
>
>
>
>
>
>
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
>
> > On 12/03/2011 02:13 AM, Anssi K ri inen wrote:
>
> > > Admin should be fixed [#2259]. Making PK fields non-editable in
> > > ModelForms would be good, too. Is it OK to consider the current
> > > ModelForm behavior a bug, or will it need a deprecation cycle?
>
> > I think it would need a deprecation cycle. People certainly could be
> > making use of the current behavior (and there would need to be a way to
> > get the PK field back into the form, e.g. by explicitly listing it in
> > "fields"). Excluding PK from ModelForm by default isn't clearly fixing a
> > bug, it's more protecting people from unintuitive behavior.
>
> > (Note that in admin we have the option to display it read-only by
> > default; ModelForm has no such feature, we'd have to exclude it entirely
> > by default).
>
> This turns out to be a show-stopper. I think that in admin we could
> just make the field non-editable when editing an object, but editable
> when saving a new object. Save-as-new would be a problem, but probably
> some workaround could be found.
>
> But for ModelForms, what to do? You would want to have the same
> behavior as in admin: editable when adding, but non-editable when
> editing an existing object. But the problem is, we do not have the
> ability to show the value as non-editable. Could this be implemented
> by a html attribute editable="false"? Ugly, but should work for most
> cases.
>
> I do agree this needs a deprecation cycle.
>
> > > It is OK that Django doesn't support primary key updates. But if it
> > > doesn't support update of PK, then lets error out on primary key
> > > change. Current behavior of .save() is actually: "save the object to
> > > DB, except when PK has changed, then do a clone". That is a bad API
> > > for natural primary keys.
>
> > > About breaking current code: my intention is to have a flag to .save()
> > > which would allow current code to work. .save(clone=True) would get
> > > current behavior back. Setting the PK to None and doing a save will
> > > work for AutoField PKs.
>
> > So what about admin users who are currently relying on this behavior as
> > a way to clone objects with natural PKs (given that the
> > save-and-add-another button is useless with natural PKs unless you can
> > explicitly give the value for the new row)?
>
> Javascript magic? save-as-new disabled for natural PKs, instead you
> get a "copy" button which opens another window? In other words, good
> ideas welcome...
>
>  - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: load template tag library

[Stephen Burrows]

I second what Luke and Russ have already said.

If what you're interested in is a way to securely allow users to enter
template code into the database, you can just write a custom field
that validates its input for security problems.

Here's a third-party implementation of a validator for such a field:
https://github.com/ithinksw/philo/blob/master/philo/validators.py#L106

This particular implementation:

- lets you explicitly allow particular tags (in which case all other
tags are disallowed for the field)
- lets you explicitly disallow particular tags (in which case all
other tags are allowed for the field)
- disallows the load, extends, include, and debug template tags by
default, but lets the backend developer specify the field as
"insecure" if they want to.

My point being - if what you want is to let people specify template
code in database fields, there are ways to make it secure without
rewriting the template engine.

On Nov 16, 4:04 pm, Russell Keith-Magee 
wrote:
> On Wed, Nov 16, 2011 at 5:12 PM, Roald  wrote:
> > Hi all,
>
> > Can anybody explain why template tag libraries are loaded from
> > *inside* a template? The more I work with them, the more I get the
> > feeling that specifying which template tags are available in a
> > template should be specified in the view-code (or more general: the
> > thing that loads/renders the template). Why would I, as a back-end
> > developer, make *all* of my template tags available to the front-end
> > developer in *all* templates?
>
> I'm afraid I don't follow how it would make sense for template tags to
> be loaded anywhere *except* inside a template.
>
>  * The view constructs the context data that is to be available for rendering.
>
>  * The template determines how that context data will be rendered.
>
>  * A template tag is a block of functionality that can be used to
> manipulate the display of data.
>
> The decision to use a particular template tag is entirely a front-end
> decision. True, it might require some coordination with backend
> developers to provide specific functionality (e.g., writing a specific
> data transformation, or writing a tag to extract specific data), but I
> fail to see how that division of labor suggests that the decision to
> make a template tag available at all should be controlled by the
> backend developer.
>
> > A great benefit of moving the template tag library loading to code,
> > would be that the template language could also be safely used in
> > CharFields/TextFields, without the risk of users using unwanted
> > template tags.
>
> If I'm understanding this correctly, your use case here is putting
> template content into a CharField or TextField, but you don't want to
> be subjected to injection-style attacks from on user content. This
> strikes me as a pretty obscure edge case to drive the design of the
> template language.
>
> > Of course, for backward compatibility, this can't be changed. The
> > thing I'm most interested in, though, is restricting the template tag
> > libraries that can be used in a template from my view-code. This can
> > be done in a backward compatible way.
>
> As with Luke, count me as a -1 on this. Luke's final paragraph sums up
> the situation nicely, IMHO:
>
>     if your use case is "allow end users to use the template
>     system safely", this feature wouldn't come close to doing that.
>     If your use case is "stop front-end developers deliberately doing
>     naughty things", I'd say the solution can't be a technical one.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: contrib.sessions test oddities

[Stephen Burrows]

Hi,

It sounds like you're looking at tests for
django.contrib.sessions.backends.cached_db. If that is the case, then
it's not unusual that you would end up calling the LocMem cache
backend. The cached_db session backend does all of its reads from the
cache, only falling back to the database sessions if the key is not
found in the cache. So, unless you define a different cache backend in
your settings.py file, the cached_db session backend will use the
LocMem cache backend.

That doesn't necessarily mean you haven't run into a problem, of
course. But it may explain some of what you're experiencing.

Best,
Stephen Burrows

On Oct 4, 9:22 pm, Justin Holmes <jus...@justinholmes.com> wrote:
> I posted this message on -users today, but at PaulM's urging, I'm
> bringing it over here out of concern that it may reflect a bug in the
> contrib.sessions test suite.
>
> Here's the original message from -users (some -dev only notes follow) :
>
> I am having a problem with contrib.sessions.tests.test_valid_key (line
> 159).  It's a mixin which in the failure case is mixed with
> CacheDBSessionTests.
>
> The test raises:
>
> "AttributeError: 'bool' object has no attribute 'get'"
>
> The error is actually raised by session.save() on 164.
>
> Stepping inward reveals that sessions.backends.cached_db (line 18)
> sets data thusly:
>
> data = cache.get(self.session_key, None)
>
> QUESTION #1 (maybe more suited for django-dev?): If I step in, I find
> that debugging core.cache.backends.locmem.LocMemCache.get(), which is
> odd since the TestCase is CacheDBSessionTests.  Why is it testing
> LocMemCache and not core.cache.backends.db.DatabaseCache?
>
> In this case, self.session_key is 1, and indeed the cache has a
> pickled "True" for the key 1.  In fact, during the course of debugging
> core.cache.backends.locmem.LocMemCache.get(), we have found that in
> every case during which the testrunner hits this method, 1 is a key
> for pickled True.
>
> QUESTION #2: Why is the key 1 set to a pickled True?
>
> In this case, that True ends up being returned in
> contrib.sessions.backends.base.SessionBase.get() (line 64).
>
> Thus, of course an error is raised.  We are unable to understand why
> the key 1 is set to pickled True in the locmem backend.
>
> NOW THE STRANGE PART:
>
> Iff we step in with a debugger and wait for > 3 seconds or so, the
> method no longer returns True and instead returns an empty dict.  In
> this case, the test passes!
>
> We are baffled.  Is this possibly an underlying race condition or
> hotel room scenario (http://stackoverflow.com/questions/6441218)?
>
> [END DJANGO-USERS MESSAGE]
>
> I also want to point a few additional things here on the dev list:
>
> *We have tried this on two different computers with OSX and Linux and
> we encounter the timing issue either way, every time.
> *We put a breakpoint on django.core.cache.backends.db.get() (line 38)
> which was never hit during the course of the sessions tests.
> *We were hoping to find that the test runner hit one backend if we
> didn't wait in state and another if we did.  However, as noted in the
> point above, that doesn't appear to be the case (unless we're missing
> something about the way the backends are implemented, which is
> possible)
> *Thinking that using cached_db for the backend might result in .get()
> being used only in LocMem, we also put a breakpoint in
> backends.db.set(), thinking that both were going to be set.  This
> breakpoint was also never hit during the course of the sessions tests.
> *The commit comment, by Russell Keith-Magee, seems like it is likely
> related: "Fixed #15026 -- Added cleanup to the invalid key session
> tests; when using Memcached as a cache backend, the cache-backed
> session backends would fail on the second run due to leftover cache
> artefacts. Thanks to jsdalton for the report and patch."
> *#15026 seems to describe a substantially different problem, but it is
> possible that the root cause is similar or the same: that unflushed
> material in the cache persists between tests.
>
> We encountered this issue at DiscSpace, which is cool enough to let
> freelancers work on issues in the django internals on company time if
> we encounter them.
>
> --
> Justin Holmes
>
> Head Instructor, SlashRoot Collective
> SlashRoot: Coffee House and Tech Dojo
> 60 Main Street
> New Paltz, NY 12561
> 845.633.8330

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: deprecation vs removal

[Stephen Burrows]

As a native speaker, I've never had a problem with the words or
phrases being discussed here. Sure, it's jargon. It might be more
accessible if we used other language. I don't really care one way or
the other. But it's jargon. The fact that Miriam-Webster doesn't know
what the word actually means doesn't prove that we're using it wrong.
Mainstream dictionaries often don't include technical jargon.

See also:

- http://en.wiktionary.org/wiki/deprecate :: (computing) To declare
something obsolescent, i.e., to recommend against a function,
technique, command, etc, that still works but has been replaced.
- en.wikipedia.org/wiki/Deprecate

Best,
Stephen Burrows

On Oct 2, 2:07 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
> 2011/10/2 Alexander Schepanovski <suor@gmail.com>:> Then when I
> upgrade django I'll just upgrade it and fix> any wrong calls, imports,
> monkey patches etc. Proper upgrading docs,> which you write anyway,
> will make it into a couple of days. The way it> is done now still
> requires that two days but also make me think about> separate
> deprecation concept, about what part of django is public and> what is
> not cause they have separate deprecation policies. It also> encourages
> me to sl
> I prefer to just run my test suite with warnings enabled and see where
> deprecated functions pop-up. The best part is that *I* choose when to
> spend time on getting rid of them and I don't have to do it all at
> once. I do this even with my own codebase.
>
> On 2 October 2011 07:48, Alexander Schepanovski <suor@gmail.com> wrote:
>
> > But even a common user, who himself doesn't hack into django may use
> > third-party libs that do: migration, automatic caching, any orm, form
> > and template extenders. And for the developers of that libs
> > deprecation is a waste not help, at least what it feels for me. For
> > common user this means he cannot upgrade until all hos libs upgraded
> > or he himself is forced into hacking them.
>
> IMHO, it's exactly the opposite. If you remove the code right away,
> then I can't upgrade to the new version of Django, 'cause I have to
> wait for my 30 dependencies to upgrade or hack it my own.
>
> ---
>
> As for the naming, it's probably because i'm not a native speaker, but
> I always found the warning names logical. "PendingDeprecationWarning"
> warns you about something, that will be deprecated in the version.
> "DeprecationWarning" warns you that something *is* deprecated (as in
> old and useless), so it *may* be removed in any future version.
>
> Whether it is actually removed is another thing - Python itself has a
> long tradition of leaving some C API functions deprecated for
> indefinite period of time. So, to me, deprecation is the state right
> before removal. I would stay with "X will be deprecated in Django Y.Z"
> wording (which implies it may be removed in any (Y+m).(Z+1+n) n,m>=0
> version).
>
> --
> Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Weekly Check-in

[Stephen Burrows]

> I found some use cases that are not yet possible with the form rendering
> template tags. The biggest issue is that it's not possible to exchange field
> labels with translated text. Currently there is no way of storing a translated
> string in the templates as variable, like {% trans "foo" as var %}

Can't you already do this with blocktrans? [1]

--Stephen

[1] 
https://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#blocktrans-template-tag

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: initial_data and post_syncdb conflicts

[Stephen Burrows]

Perhaps I'm missing something... initial_data is "test-only", right?
As opposed to other fixtures which should always be loaded? Then why
would the other fixtures rely on the initial_data?

On Aug 18, 4:15 pm, David Cramer  wrote:
> We've been working on switching our test suite to use some new "super
> fixtures", which are really just global, test-only initial_data style
> fixtures. To implement this we attach to the post_syncdb, and set a
> runonce-per-db flag (since it seems to be the only available signal),
> but we hit some issues with the way the process flow works for flush/
> syncdb.
>
> Basically, all the code goes:
>
> {flush,syncdb} => {db actions} => emit post_syncdb => load
> initial_data
>
> In order for our hooks to work, we had to reorder load initial_data so
> that it happened before the syncdb signal was sent out. The reason
> being is that some of our fixture data relied on foreignkeys which
> were present in initial_data.
>
> My question is, would it be reasonable to change this upstream (both
> in syncdb and flush), or would it be better to possibly add some
> additional signals?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How do add ancillary, display-only data to each form in a formset?

[Stephen Burrows]

This post seems to be squarely in django-users territory, not django-
developers. Perhaps the discussion could continue there?

On Jul 22, 9:25 pm, Andre Terra  wrote:
> I'm on my phone, and therefore read your message really quickly, so
> excuse me if I misunderstood the issue.
>
> A few questions:
>
> * Have you considered using a custom widget for the form?
> * What does the ancillary data look like?
> * Could you paste the relevant model, form and view? I find it easier
> to understand issues like this if I'm looking at the code. And don't
> worry, we won't judge! Just yesterday I caught myself using 'is' for
> string comparison, so your code is probably better than mine =)
>
> Also, love the vocabulary. Keep it coming, we need more posts like this.
>
> Cheers,
> AT
>
> On 7/22/11, Chris Cogdon  wrote:
>
>
>
>
>
>
>
>
>
> > I think I did my due google diligence (googlence?) on this one, and came up
> > short.
>
> > I'm trying to pass some ancillary, read-only information along with each
> > element in a formset. Ie, Along with the stuff that can be changed by the
> > user, I'd like some stuff that can-NOT be changed. Not all, but some, of the
> > information needs to be read back during validation.
>
> > For example, I have:
>
> > class Thingy ( models.Model ):
> >    name = model.CharField ()
>
> > I have a few that selects a few Thingys and will present them to the user
> > with a checkbox next to each, so its obvious I want a form:
>
> > class CheckThingyForm ( forms.Form ):
> >    checked = forms.BooleanForm ()
>
> > CheckThingyFormset = formset_factory ( CheckThingyForm, extra=0 )
>
> > Inside the view, I create a list of the thingies I want to present
>
> >    thingies = Thingy.objects.filter ( ... some criteria... )
>
> > and now to... somehow... create the initial data for the formset. This is
> > where I am stumped. I've tried something like the following:
>
> >    thingies_list = []
> >    for thingy in thingies:
> >            thingies_list.append ( { 'thingy': thingy } )
>
> >    formset = CheckThingyFormset ( initial = thingies_list )
>
> > And while this presents the correct number of rows, my expectation on being
> > able to extract the thingy in the template fails. "form.thingy.name" returns
> > nothing
>
> > {% for form in formset %}
> > {{ form.checked }}{{ form.thingy.name }}
> > {% endfor %}
>
> > If I'm far more explicit about it, by using the following, i still turn up a
> > blank
>
> > thingies_list.append ( { 'name': thingy.name } )
>
> > What's the "right" way of passing ancillary data to a formset like this? If
> > it was just a single form, then I could very easily just pass the data i
> > needed through additional context variables. But since here I want to pass
> > some data per form, and dont care about being able to read it back or not,
> > it makes sense to try and pass it along WITH the form, and not need it to be
> > a field itself to read back.
>
> > (What I omitted was needing to pass thingy.id, so I know what thingy I'm
> > actually checking when validating the form... obviously I should include
> > that in the form or an "add_fields in the formset, and have it as a
> > hidden... I could do the same thing with the "name" and just extract the
> > value explicitly, but that's really contorted)
>
> > Thanks for reading this far... I hope someone can help.
>
> > --
> >   ("`-/")_.-'"``-._        Chris Cogdon 
> >    . . `; -._    )-;-,_`)
> >   (v_,)'  _  )`-.\  ``-'
> >  _.- _..-_/ / ((.'
> > ((,.-'   ((,/   fL
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> Sent from my mobile device

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Admin inlines and fieldsets

[Stephen Burrows]

Hey,
I reopened the ticket and suggested a syntax that would make more
sense to me than the options already presented there.
Best,
Stephen

On Jun 27, 10:00 am, Russell Keith-Magee 
wrote:
> On Mon, Jun 20, 2011 at 7:51 PM, Aymeric Augustin
>
>
>
>
>
>
>
>
>
>  wrote:
> > Hello,
> > Ticket #10938 [1] suggests declaring inlines in fieldsets, and was closed as
> > wontfix.
> > I think this ticket mixes two different things:
> >     (1) make it possible to *declare* inlines in
> > ModelAdmin.fieldsets instead of ModelAdmin.inlines. This is a bad idea:
> > there should be only one way to declare inlines, and the current way is OK.
> >     (2) make it possible to *include* inlines in ModelAdmin.fieldsets (with
> > a syntax that's still to be defined) in order to chose the position of the
> > inlines in the change form. I think it's useful; actually, I need that right
> > now.
> > Currently, inlines are added at the bottom of the change form — see
> > templates/admin/change_form.html — and displaying them in another position
> > involves re-ordering things with javascript or overriding the change form
> > template. It would be easier if fieldsests accepted both fields and inlines
> > in fieldsets.
> > Reading Russell's closing comment, it looks like he had (1) in mind but not
> > (2). Does the wontfix also apply to (2)?
>
> Hi Aymeric,
>
> Apologies for taking a while to get back to you on this.
>
> You're correct -- I had (1) in mind when I wontfixed the ticket.
> However, I can certainly see the merit in interpretation (2) providing
> a way to include inlines in fieldsets as an organizational/ordering
> mechanism. This general feature request (i.e., ordering of inlines
> within normal field organization) is something that has been proposed
> several times in the past -- in fact, I'd be surprised if there isn't
> a couple of tickets relating to this.
>
> Of course, the devil is in the details -- especially, in finding a
> good syntax given that there isn't a name or label currently available
> for referencing inlines...
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: "c" date formating and Internet usage

[Stephen Burrows]

I realize I may have been a little unclear. I assumed that this
problem was surfacing with relation to datetime fields on models,
which are inherently naive. (For example, an attempt to render a blog
entry's pubdate.) If the "c" formatting option were used in
conjunction with a timezone-aware datetime, then the UTC offset would
appear.

So I'm not saying that "Django doesn't support timezone-aware
datetimes". Django passes *all* of the work for the "c" formatting
option to python's datetime.isoformat() method, which *does* support
them. Sure, we could add some sort of magic that handles naive
datetimes, but I would argue against that on the principle that the
whole reason the datetimes are naive is that one doesn't know what
time zone they're from.

The "O" formatter - or more specifically, the "Z" formatter - does
include that bit of magic. Is there a particular reason for this?
Also, if a timezone is assumed, wouldn't it make more sense to assume
the timezone of the project rather than UTC? Rather than noting an
inconsistency, can we make this consistent?

On Jun 28, 5:47 am, Yohan Boniface <yohanbonif...@gmail.com> wrote:
> Hi Stephen, Hi Ian, Hi all,
>
> As you say Stephen, isoformat is handling the timezone offset for non naive
> datetime, and so does Django in the "c" date formatter. And I should have
> noticed and mentionned this in my previous email.
> I'll take the time to give a better look to this issue, with these new
> elements.
> By the way, I wonder why for the "O" formatter a workaround is used when the
> datetime is naive, and not for the "c" formatter.
> Anyway, I think that at least a little patch to the doc to clarify the "c"
> behaviour should be useful (naive and non naive datetime). And maybe to warn
> about the non consistent behaviour of Django depending on the date formater
> used.
>
> Yohan
>
> 2011/6/27 Ian Clelland <clell...@gmail.com>
>
>
>
>
>
>
>
> > On Sun, Jun 26, 2011 at 12:27 AM, Stephen Burrows <
> > stephen.r.burr...@gmail.com> wrote:
>
> >> This is related to the recent discussion about timezone-aware datetime
> >> storage [1] and how django doesn't do it. Since the date filter's "c"
> >> argument is handled with python's datetime.isoformat() [2] timezone-
> >> naive datetimes will not display a UTC offset.
>
> >> [1]
> >>http://groups.google.com/group/django-developers/browse_thread/thread...
>
> >> [2]
> >>http://docs.python.org/library/datetime.html#datetime.datetime.isoformat
>
> > This isn't the same issue at all -- It may be related, but that discussion
> > thread was about storing timezone-aware timestamps in the database, not
> > about handling them in templates.
>
> > We can't simply say that "Django doesn't support
> > timezone-aware datetimes" -- besides being a ridiculous restriction, it's
> > not true: even in django.utils.dateformat there are several formatting codes
> > that take the input's timezone into account (see I, o, T, U).
>
> > Even the "r" formatting code, for RFC 822 formatting, takes the timezone,
> > if present, into account.
>
> > While I would use the documented claim of PHP compatibility as an argument
> > for this, it's not really a strong argument (and I wouldn't support just
> > removing the claim as a simple solution). A better argument is that the ISO
> > standard allows the timezone, various Internet standards and drafts
> > recommend or require it, and in many cases, it is available to Django, and
> > so we should include it when we can.
>
> > I generally find myself having to introduce a "proper" ISO-8601 formatting
> > string into every project, or supplement the time rendering with a
> > hard-coded timezone, when I can know it for sure (e.g., {{
> > timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real"
> > ISO-8601 formatter to the standard filter library.
>
> > --
> > Regards,
> > Ian Clelland
> > <clell...@gmail.com>
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Timezone-aware storage of DateTime

[Stephen Burrows]

I agree that it would be nice to be able to store tz-aware datetimes -
but if django were going to do so, it ought to store the datetimes
with the timezone information intact, rather than converting
everything to the project's timezone. So, if a conversion to UTC were
to take place, there would need to be a separate field in the database
to store the timezone.

On Jun 27, 3:12 pm, Sam Bull <osir...@gmail.com> wrote:
> On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
>
> > Django actually already adds support for some capabilities to certain
> > database backends, if I'm not mistaken - such as cascades through GFKs
> > on delete.
>
> > In terms of time zones, could django "assume"/ensure that the datetime
> > stored in the backend is UTC, then handle the conversion to the local
> > timezone itself?
>
> Isn't this a viable solution? It's the universal, cross-timezone-friendly 
> datetime objects that we care about, not the timezones they were in, right?
>
> - If the DB supports timezone-aware datetime fields, just pass the datetime 
> object through as is.
>
> - If the DB doesn't support timezone-aware datetime fields, convert to UTC 
> and store the datetime as UTC
>
>   - If the datetime has tz info, convert the time to UTC using that
>
>   - If the datetime doesn't have tz info, convert using the default timezone 
> specified in the settings
>
> When retrieving the data from a non-timezone-aware db, convert them from UTC 
> to the project's timezone.
>
> Sam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: "c" date formating and Internet usage

[Stephen Burrows]

This is related to the recent discussion about timezone-aware datetime
storage [1] and how django doesn't do it. Since the date filter's "c"
argument is handled with python's datetime.isoformat() [2] timezone-
naive datetimes will not display a UTC offset.

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/76e2b486d561ab79/0a46b72da6e9fb03

[2] http://docs.python.org/library/datetime.html#datetime.datetime.isoformat

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 5-for-1?

[Stephen Burrows]

Thanks for having a look at the ticket. I'd be happy to rewrite the
patch to include **kwargs support, if that's what people want.
However, there's no precedent in django for a tag accepting args *and*
kwargs (that I am aware of.) What would the syntax look like?

{% simple_tag arg1 arg2 with hi="low" foo="bar" %}?

{% simple_tag with arg1 arg2 hi="low" foo="bar" %}?

{% simple_tag arg1 arg2 hi="low" foo="bar" %}?

@Sam Bull: Looking at fancy_tag, I think that turning it into a patch
might be as much or more work than just converting the current patch
to also support kwargs.

On Jun 18, 10:12 am, Sam Bull <osir...@gmail.com> wrote:
> Hey,
>
> I've got a reusable app that offers the functionality you're looking for, I 
> think. I just commented on the ticket, so I hope this doesn't count as 
> double-posting, but you can check it out 
> here:https://github.com/trapeze/fancy_tag
>
> It's got unit tests, keyword argument support (like the new with tag), *args 
> support, **kwargs support, and support for the "with " pattern.
>
> Is this something I should convert into a patch?
>
> Sam
>
> On 2011-06-18, at 5:29 AM, Jannis Leidel wrote:
>
>
>
>
>
>
>
> > On 18.06.2011, at 03:38, Stephen Burrows wrote:
>
> >> I would love it if someone could look at 13956 [1]
>
> >> [1]http://code.djangoproject.com/ticket/13956
>
> > I'd like to repeat my concerns from the ticket that it seems odd to extend 
> > the
> > helper tags with support for *args but leaving out **kwargs. If the API of
> > those tags should be extended with concepts from Python we shouldn't do this
> > only partially.
>
> > Fortunately there is a good (new) convention in Django how to write kwarg
> > style template parameters, thanks to Chris Beaven's with/include tag 
> > refactor
> > (``{% with arg1=1 arg2=2 %}{{ arg1 }}: {{ args2 }}{% endwith %}``), which
> > could also be used for the tag helpers.
>
> > Jannis
>
> >> On Jun 7, 12:24 pm, Carl Meyer <c...@oddbird.net> wrote:
> >>> Hi Stephen,
>
> >>> On 06/07/2011 02:37 AM, Stephen Burrows wrote:
>
> >>>> Hi - is the 5-for-1 deal still active on ticket reviews? [1]
> >>>> If so, I've reviewed the following tickets:
>
> >>>> 3624
> >>>> 16152
> >>>> 16157
> >>>> 16158
> >>>> 16166
>
> >>>> And would love it if someone could have a look at ticket 14082 [2].
>
> >>>> If not, ah well. :-)
>
> >>> Thanks for the ticket reviews, and your work on the patch. Committed in
> >>> r16334 [1]
>
> >>> Carl
>
> >>>  [1]https://code.djangoproject.com/changeset/16334
>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "Django developers" group.
> >> To post to this group, send email to django-developers@googlegroups.com.
> >> To unsubscribe from this group, send email to 
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group 
> >> athttp://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 5-for-1?

[Stephen Burrows]

Thanks, Carl. :-)

I probably should've written a thank you note sooner & separately. As
it is, I am also writing to request a five-for-one again.
I have reviewed:
16168
16173
16176
16235
16237

I would love it if someone could look at 13956 [1]

Best,
Stephen

[1] http://code.djangoproject.com/ticket/13956

On Jun 7, 12:24 pm, Carl Meyer <c...@oddbird.net> wrote:
> Hi Stephen,
>
> On 06/07/2011 02:37 AM, Stephen Burrows wrote:
>
> > Hi - is the 5-for-1 deal still active on ticket reviews? [1]
> > If so, I've reviewed the following tickets:
>
> > 3624
> > 16152
> > 16157
> > 16158
> > 16166
>
> > And would love it if someone could have a look at ticket 14082 [2].
>
> > If not, ah well. :-)
>
> Thanks for the ticket reviews, and your work on the patch. Committed in
> r16334 [1]
>
> Carl
>
>   [1]https://code.djangoproject.com/changeset/16334

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Error Display Page

[Stephen Burrows]

On Jun 10, 3:34 am, Dougal Matthews  wrote:
> On Friday, 10 June 2011 at 04:31, Valentin Golev wrote:
> > What I'd really like is a stacktrace in a plain text in the html
> > commentary ("") on the very top of the page.
>
> +1
>
> This would actually be very useful when debugging Ajax calls in browsers. I 
> often find myself reading the HTML particularly in chrome where I think the 
> only other option is to save the file and re-open it.
>
> Dougal

That would be useful for Chrome and Safari, and probably pretty easy
to implement. (For Firefox, I like to use the Modify Headers add-on
[1] and spoof the AJAX request - then I can browse the error page in
its full glory. :-) )

--Stephen

[1] https://addons.mozilla.org/en-us/firefox/addon/modify-headers/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

5-for-1?

[Stephen Burrows]

Hi - is the 5-for-1 deal still active on ticket reviews? [1]
If so, I've reviewed the following tickets:

3624
16152
16157
16158
16166

And would love it if someone could have a look at ticket 14082 [2].

If not, ah well. :-)

Best,
--Stephen Burrows

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/abc6cf0450812d82?pli=1
[2] https://code.djangoproject.com/ticket/14082

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Vote on {% include %} behaviour.

[Stephen Burrows]

#12008 was repurposed as a documentation improvement because the
current implementation is correct and just needs to be explained
better. As for the other two... I agree that consistency is important,
and that it would make sense (in a way) for ConstantIncludeNode to
either always raise or always silence, but that can definitely be done
without removing the CIN or hacking together some other way to get
similar compilation caching.

It's also worth mentioning that if TEMPLATE_DEBUG is set to ``True``,
the (non-constant) IncludeNode will raise an exception when it
*renders*, even though the Django docs clearly state that "render()
should never raise TemplateSyntaxError or any other exception. It
should fail silently, just as template filters should." If anything,
this is a more egregious error than ConstantIncludeNode's behavior.

That being said, whatever is decided, perhaps it could be applied to
the ExtendsNode as well? Right now, constant extends are loaded at the
same time as variable extends - handling constants differently could
give a similar performance boost there. In fact, there's a ticket open
to do just that: https://code.djangoproject.com/ticket/6586.

On Jun 3, 5:12 pm, Luke Plant  wrote:
> On 03/06/11 17:36, Aymeric Augustin wrote:
>
> > ConstantIncludeNode improves performance because it calls
> > django.template.loader.get_template() only once in __init__() and not
> > in each call to render().
>
> > get_template() invokes the template loading machinery to create a
> > compiled Template object, given a template path. If it's a
> > performance bottleneck, we can memoize its results. That will improve
> > performance of all template lookup operations, not only {% include
> > %}.
>
> We already have the cached template loader, and we don't want to invoke
> that kind of behaviour unless asked for (it's up to users to put it in
> their TEMPLATE_LOADERS settings), as it has significant memory overhead.
>
> I was thinking something simpler, like this:
>
> class IncludeNode(BaseIncludeNode):
>     def __init__(self, template_name, *args, **kwargs):
>         super(IncludeNode, self).__init__(*args, **kwargs)
>         self.template_name = template_name
>
>     def render(self, context):
>         try:
>             template_name = self.template_name.resolve(context)
>             if getattr(self, 'last_template_name', None) == \
>                     template_name:
>                 template = self.template
>             else:
>                 template = get_template(template_name)
>                 self.template = template
>                 self.last_template_name = template_name
>             return self.render_template(template, context)
>         except:
>             if settings.TEMPLATE_DEBUG:
>                 raise
>             return ''
>
> If I'm thinking correctly, that will keep the included template in
> memory only for the lifetime of the parent template, and will avoid
> loading it more than once if it is a static string and the include is in
> a loop.
>
> Luke
>
> --
> "Underachievement: The tallest blade of grass is the first to be
> cut by the lawnmower." (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Timezone-aware storage of DateTime

[Stephen Burrows]

Django actually already adds support for some capabilities to certain
database backends, if I'm not mistaken - such as cascades through GFKs
on delete.

In terms of time zones, could django "assume"/ensure that the datetime
stored in the backend is UTC, then handle the conversion to the local
timezone itself?

On Jun 1, 9:16 am, VernonCole  wrote:
> On May 31, 7:23 am, Daniel Swarbrick 
> wrote:> I can almost hear the collective sigh as this topic once again rears
> > up ;-)
>
> Thanks for bringing it up.  I lurk both here and on db-sig, and intend
> to use your well done research to once again attempt an update of the
> db-api PEP, which also does not address time zone aware time.  I like
> the idea of standardizing a cross-platform TZ aware data column.
> [...]
>
> > The way I see it, there are a few options for storage of timestamps in
> > SQLite (whose docs clearly acknowledge that it does not officially
> > support a timestamp column type).
>
> > 1. Store timestamps as a Unix epoch value (integer). This is fast, and
> > will ensure correct date sorting. On the other hand, it's not really
> > human-friendly if manually browsing table data in SQLite.
>
> Not only is the epoch limited in range, I would be wary of using any
> storage based on the python time module (as opposed to datetime).  We
> have discovered enough subtle bugs in the Windows and IronPython
> implementations that we gave up trying to get an accurate test of the
> python time option on adodbapi. Things that worked correctly for me in
> North America would fail for Mark Hammond in Australia. It is a maze
> of twisty little passages. We simply recommend that everyone use
> datetime.
>
> On the other hand, I found it necessary to convert date-time values to
> ISO format strings in order to feed them to Microsoft ACCESS databases
> in some cases, and that works well. But again, as with SQLite, the DB
> has no concept of time zones. In the absence of actual time zone
> support in the database, any action taken by django is going to
> inconvenience somebody, and will likely not be compatible with non-
> django use of the same database.  Perhaps it would work to store the
> pickled tz-aware datetime on brain-damaged databases.  But, is it
> reasonable to use an application-specific method to extend the
> capability of a database engine?
> --
> Vernon Cole

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: switch to HTML5 for bundled templates

[Stephen Burrows]

Anyone interested in reading about html5 can find a lot of great
information at http://diveintohtml5.org/.

Some of the highlights:

1. a change to the doctype of the admin from http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd"> to  should still keep ie6 in Almost
Standards Mode [1]

2. Browsers degrade the new form inputs gracefully [2]

3. There is a simple workaround going back to ie6 for handling the css
problems related to unrecognized tags. [3]

[1] http://hsivonen.iki.fi/doctype/

[2] http://diveintohtml5.org/forms.html#type-email

[3] http://diveintohtml5.org/semantics.html#unknown-elements

On Mar 28, 11:36 pm, Julien Phalip  wrote:
> On Mar 29, 2:29 pm, Julien Phalip  wrote:
>
>
>
>
>
>
>
>
>
> > On Mar 29, 1:26 pm, Luke Plant  wrote:
>
> > > The further enhancements I'm thinking of are things like an EmailInput
> > > widget (which I'd suggest was the default widget for EmailField, but
> > > could be just available in django/forms/widgets.py). This widget would
> > > output .  AFAIK, this is fully backwards compatible
> > > with browsers that don't support it, since  default to
> > > type="text" if the browser doesn't recognise the "type" attribute.
>
> > This commodity with input types (particularly search, tel, url and
> > email) may possibly be the only one we can offer out-of-the-box if we
> > want to continue supporting IE6 without javascript. This would still
> > be welcome though, and certainly a step in the right direction. In
> > principle, the HTML5 doctype is fully backwards and forwards
> > compatible with any browser so that can't hurt [1].
>
> > Since the patch is small, then it would be very quick to test it in
> > all browsers right away, no? :-)
>
> Further to this, although I haven't done a great deal of testing
> myself yet, I hear that old browsers sometimes aren't able to apply
> CSS rules to tags that aren't recognised or that have attributes that
> aren't recognised. So if we test this patch with old browsers we
> should also test how CSS is affected.
>
> Julien

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: type-field model inheritance

[Stephen Burrows]

It sounds like you want to make polymorphic models - queries that
retrieve various types of objects. There's an implementation of this:
https://github.com/bconstantin/django_polymorphic

On Mar 2, 9:07 pm, Craig de Stigter  wrote:
> I realise everyone's been busy with getting 1.3 ready, but doesn't anyone
> have thoughts on this? It's been two weeks ...
>
> Thanks
> Craig
>
> On Thursday, February 17, 2011 11:08:57 PM UTC+13, Craig de Stigter wrote:
>
> > Hi folks
>
> > Ever since Django started supporting various types of model inheritance
> > I've wondered why it lacks the kind that I would find most useful: python
> > behaviour differentiated based on the value of a field.
>
> > I'll explain with an example. Here's what I'd like to do:
>
> > class Datasource(models.Model):
> >     type = models.ModelTypeField()
> >     uri = models.CharField(max_length=256)
>
> >     # common behavior in the superclass
> >     def __repr__(self):
> >         return u'<%s: %s>' % (self.__class__.__name__, self.uri)
>
> > class HttpDatasource(Datasource):
> >     # custom behaviour in the subclasses
> >     def get_filename(self):
> >         return self.uri.rsplit("/", 1)[-1]
>
> > class ZipfileDatasource(Datasource):
> >     def get_filename(self):
> >         files = zipfile.list(self.uri)
> >         return files[0].rsplit('/', 1)[-1]
>
> > >>> zip = ZipfileDatasource.objects.create(uri="/path/to/foo.zip")
> > >>> uri = UriDatasource.objects.create(uri="http://example.com/foo.txt;)
>
> > >>> Datasource.objects.all()
> > [,  >http://example.com/foo.txt>]
>
> > >>>ZipfileDatasource.objects.all()
> > []
>
> > >>> Datasource.objects.all().values_list('type', flat=True)
> > [u'myapp.models.ZipfileDatasource', u'myapp.models.UriDatasource']
>
> > These are quite similar to proxy models, but vary in their queryset
> > behaviour - the generic Datasource queryset has mixed types and the concrete
> > querysets are always filtered by type.
>
> > This is far more useful than proxy models, since the concrete types of each
> > table are known. It's also better than making an abstract model and
> > subclassing it, because now all the objects are in the same table and you
> > can iterate over them all at once if you want. Adding more types is easy,
> > since there are no schema changes (with abstract models you'd have to add a
> > new table for each type).
>
> > It's possible that proxy models could be extended to do this without
> > breaking existing code. I'm not sure yet.
>
> > I'm thinking of diving into this. Does anyone have any suggestions? Or,
> > perhaps there's a reason why this hasn't been done previously that you more
> > experienced gurus could illuminate?
>
> > Thanks in advance
>
> > Craig de Stigter
> > Maintainer of django-mptt and full time dev at koordinates.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Getting Slammed Hard on Foreign Keys in the admin due to __unicode__

[Stephen Burrows]

Though it's a little hard to tell from your post, this sounds more
like it's definitely a case where your code needs improvement. From
what I understand, the database hits are coming from your custom AJAX,
not from the admin's default behavior. Also, you already know the
solution: use select_related. If you are saying that django ORM should
make select_related=True the default - no. That would be bad. Every
query for a model with a foreign key would be bloated by the
additional joins and selects, whether or not any of the data on the fk
was being used. Overall efficiency might actually decrease.
To put it another way, "Premature optimization is the root of all
evil."
Best,
Stephen


On Feb 13, 10:35 pm, Matteius  wrote:
> I have a very small test database on my test development virtualbox
> environment and so while I've been adding in custom AJAX for dynamic
> ForeignKey filters (in the case of Enrollment's Assignment list) I
> noticed that because I'm using the Django Debug Toolbar.  Well on
> these pages with only ~28 Enrollments I get hit up with 72 queries and
> the page takes 780 ms to load.  Well this could probably be solved by
> adding select_related() to the lookups on foreign key fields or at
> least something.  This is terrible default behavior, but I can't
> really ship an admin interface to the client without showing the
> relationship in the system.  This is definitely a case where the admin
> needs improvement.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Inheritance of rel fields from base classes should not cause conflicts if the base classes involved are all abstract.

[Stephen Burrows]

Thanks for the feedback. I've opened a ticket at 
http://code.djangoproject.com/ticket/15279.
I did take a look at #14705, but though it is related topically, there
didn't seem to be a way to exploit those changes for the effect I'm
trying to achieve. My patch does still need improvement, docs, and
tests; I plan to do that next week.
Best,
Stephen Burrows

On Feb 10, 1:48 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, Feb 9, 2011 at 1:43 AM, Stephen Burrows
>
>
>
>
>
>
>
>
>
> <stephen.r.burr...@gmail.com> wrote:
> > Hi! I was going to submit this as a ticket, but I glanced over the patch
> > submission guidelines once more and this seems to fall under the category of
> > a "non-trivial change" that would require a design decision. The code
> > samples/tracebacks can be viewed nicely formatted on github. [1]
> > Assume the following models in `app`:
> > from django.db import models
>
> > class Orange(models.Model):
> >     pass
>
> > class BaseClass(models.Model):
> >     field = models.ForeignKey(Orange)
> >     class Meta:
> >         abstract = True
>
> > class Parent1(BaseClass):
> >     class Meta:
> >         abstract=True
>
> > class Parent2(BaseClass):
> >     class Meta:
> >         abstract=True
>
> > class Child(Parent1, Parent2):
> >     pass
> > Currently, this definition will raise the following errors during model
> > validation:
>
> > Unhandled exception in thread started by  > >
> > Traceback (most recent call last):
> >   File "/django/core/management/commands/runserver.py", line 88, in
> > inner_run
> >     self.validate(display_num_errors=True)
> >   File "/django/core/management/base.py", line 253, in validate
> >     raise CommandError("One or more models did not validate:\n%s" %
> > error_text)
> > django.core.management.base.CommandError: One or more models did not
> > validate:
> > app.child: Accessor for field 'field' clashes with related field
> > 'Orange.child_set'. Add a related_name argument to the definition for
> > 'field'.
> > app.child: Accessor for field 'field' clashes with related field
> > 'Orange.child_set'. Add a related_name argument to the definition for
> > 'field'.
> > Using the %(app_label)s_%(class)s_related syntax only makes things worse:
>
> > Unhandled exception in thread started by  > >
> > Traceback (most recent call last):
> >   File "/django/core/management/commands/runserver.py", line 88, in
> > inner_run
> >     self.validate(display_num_errors=True)
> >   File "/django/core/management/base.py", line 253, in validate
> >     raise CommandError("One or more models did not validate:\n%s" %
> > error_text)
> > django.core.management.base.CommandError: One or more models did not
> > validate:
> > app.child: Accessor for field 'field' clashes with related field
> > 'Orange.app_child_related'. Add a related_name argument to the definition
> > for 'field'.
> > app.child: Reverse query name for field 'field' clashes with related field
> > 'Orange.app_child_related'. Add a related_name argument to the definition
> > for 'field'.
> > app.child: Accessor for field 'field' clashes with related field
> > 'Orange.app_child_related'. Add a related_name argument to the definition
> > for 'field'.
> > app.child: Reverse query name for field 'field' clashes with related field
> > 'Orange.app_child_related'. Add a related_name argument to the definition
> > for 'field'.
>
> > Instead of causing errors, it seems like the field should only be inherited
> > once from BaseClass.
>
> I don't think this is very controversial at all -- I can't see any
> reason why BaseClass.field should be represented twice in Child's
> field list.
>
> > My patch [1] handles this as follows: On each field
> > instance, track the class it was originally declared for and the first
> > non-abstract class that it shows up in. Then, when a field is being added to
> > a class, check to make sure that it only gets added if it isn't a
> > "duplicate". (The patch would incidentally also need to move the
> > get_FIELD_display method declaration [2] into cls._meta.add_field.) If this
> > is an acceptable idea, I would be happy to add tests and docs. If the
> > general idea is acceptable, but the implementation is flawed, I would be
> > happy to write patches using other methods that people may suggest; this was
> > just what made sense to me.
>
> Thanks 

Inheritance of rel fields from base classes should not cause conflicts if the base classes involved are all abstract.

[Stephen Burrows]

Hi! I was going to submit this as a ticket, but I glanced over the patch
submission guidelines once more and this seems to fall under the category of
a "non-trivial change" that would require a design decision. The code
samples/tracebacks can be viewed nicely formatted on github. [1]

Assume the following models in `app`:

from django.db import models


class Orange(models.Model):
pass


class BaseClass(models.Model):
field = models.ForeignKey(Orange)
class Meta:
abstract = True


class Parent1(BaseClass):
class Meta:
abstract=True


class Parent2(BaseClass):
class Meta:
abstract=True


class Child(Parent1, Parent2):
pass

Currently, this definition will raise the following errors during model
validation:


Unhandled exception in thread started by >
Traceback (most recent call last):
  File "/django/core/management/commands/runserver.py", line 88, in
inner_run
self.validate(display_num_errors=True)
  File "/django/core/management/base.py", line 253, in validate
raise CommandError("One or more models did not validate:\n%s" %
error_text)
django.core.management.base.CommandError: One or more models did not
validate:
app.child: Accessor for field 'field' clashes with related field
'Orange.child_set'. Add a related_name argument to the definition for
'field'.
app.child: Accessor for field 'field' clashes with related field
'Orange.child_set'. Add a related_name argument to the definition for
'field'.

Using the %(app_label)s_%(class)s_related syntax only makes things worse:


Unhandled exception in thread started by >
Traceback (most recent call last):
  File "/django/core/management/commands/runserver.py", line 88, in
inner_run
self.validate(display_num_errors=True)
  File "/django/core/management/base.py", line 253, in validate
raise CommandError("One or more models did not validate:\n%s" %
error_text)
django.core.management.base.CommandError: One or more models did not
validate:
app.child: Accessor for field 'field' clashes with related field
'Orange.app_child_related'. Add a related_name argument to the definition
for 'field'.
app.child: Reverse query name for field 'field' clashes with related field
'Orange.app_child_related'. Add a related_name argument to the definition
for 'field'.
app.child: Accessor for field 'field' clashes with related field
'Orange.app_child_related'. Add a related_name argument to the definition
for 'field'.
app.child: Reverse query name for field 'field' clashes with related field
'Orange.app_child_related'. Add a related_name argument to the definition
for 'field'.


Instead of causing errors, it seems like the field should only be inherited
once from BaseClass. My patch [1] handles this as follows: On each field
instance, track the class it was originally declared for and the first
non-abstract class that it shows up in. Then, when a field is being added to
a class, check to make sure that it only gets added if it isn't a
"duplicate". (The patch would incidentally also need to move the
get_FIELD_display method declaration [2] into cls._meta.add_field.) If this
is an acceptable idea, I would be happy to add tests and docs. If the
general idea is acceptable, but the implementation is flawed, I would be
happy to write patches using other methods that people may suggest; this was
just what made sense to me.

Best,
Stephen Burrows

[1] http://gist.github.com/815337
[2]
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L238

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: annotating fields with null=True

[Stephen Burrows]

Perhaps I'm missing something, but if you count all the defined
foreign keys AND all the null values, won't you just end up with a
count of the parent model? Or are you saying that you explicitly want
to count how many values are null *instead of* defined?

On Jan 25, 2:39 pm, Sergiy Kuzmenko  wrote:
> Hi there!
>
> Annotating a nullable foreign field with Count seems to always return
> the count of null values as zero (at least in MySQL environment). A
> quick look into this problem reveals that the corresponding SQL clause
> is generated as `count()` [1]. This causes to exclude null
> values from annotation in MySQL [2]. I believe the same applies to
> PostgreSQL [3] and likely to other backends.
>
> In my mind, current behaviour is bit of a bug (it is definitely quirky
> in MySQL). But it is possible that not counting null values was
> intentional. In this case there should be at least a way for user to
> specify that null values must also be counted. Perhaps something like:
>
> Count(field_name, count_nulls=True)
>
> [1]http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
> [2]http://dev.mysql.com/doc/refman/5.1/en/group-by-functions.html#functi...
> [3]http://www.postgresql.org/docs/9.0/static/sql-expressions.html
>
> Thanks
> Sergiy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Problem with ``Model.objects.create``

[Stephen Burrows]

Just to clarify, an IntegrityError is raised if "the relational
integrity of the database is affected, e.g. a foreign key check fails,
duplicate key, etc." [1] Since the creation of a model instance
doesn't affect the database, it should definitely not raise an
IntegrityError. Additionally, blank=True doesn't have anything to do
with database structure: it's purely for validation django-side. The
database doesn't care whether something is blank or not, so saving an
object (or using Foo.objects.create()) with a blank value in a
required field will also not raise an IntegrityError.
That being said, if a model has a blank value in a required field, a
ValidationError should be raised by the full_clean method, and if
that's not happening, it's a bug. If you're creating a model instance
and want to run validation before you it's saved to the database,
you'll want to do the following:

>>> obj = Foo(xyz='Hello')
>>> obj.full_clean()
(Here a ValidationError will be raised. In actual code you would want
to use try/except.)
>>> obj.spam = "w/e"
>>> obj.full_clean() # since the model instance will now validate, this won't 
>>> raise an exception.
>>> obj.save()

If the ValidationError is being raised correctly, then this might be a
topic more for django-users than django-developers.

Best,
Stephen

[1] http://code.djangoproject.com/wiki/IntegrityError

On Jan 3, 12:10 am, Yo-Yo Ma  wrote:
> Oh, sorry for the confusion, and thanks for the explaination. I
> thought that Django raised an IntegrityError in this case, and when it
> didn't happen I figured it was a bug.
>
> I will make a recommendation (observation). To provide a blank value a
> a model and have it validate with full_clean, you have to specify
> blank=True. I would suggest that to maintain integrity between your
> applications logic and the database, Django should raise an
> IntegrityError, if blank=False.
>
> On Jan 2, 6:53 pm, Russell Keith-Magee 
> wrote:
>
> > On Mon, Jan 3, 2011 at 7:46 AM, Yo-Yo Ma  wrote:
> > > I apologize ahead of time, if this bug is rather a user error.
>
> > > If you have a model:
>
> > > class Foo(Model):
> > >    spam= CharField(max_length=30)
> > >    xyz= CharField(max_length=30)
>
> > >    def __unicode__(self):
> > >        return self.xyz
>
> > > and you use it in the shell like this:
>
> >  Foo.objects.create(xyz="Hello")
> > > 
>
> > > No IntegrityError was raised, even though ``spam`` is a required field.
>
> > Yes, 'spam' is a required field. And if you investigate a little
> > closer, you'll see that it has a value -- the empty string.
>
> > You'll note that the following also works, and is entirely consistent
> > with get_or_create():
>
> > >>> obj = Foo(xyz='Hello')
> > >>> obj.save()
>
> > For reasons of historical significance, the default value for all
> > fields (CharField or otherwise) is "", unless:
> >  * a default is provided by the user, or
> >  * You've overridden get_default, or
> >  * You're using Oracle (which has it's own special difficulties with "" vs 
> > None)
>
> > Yours,
> > Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ticket 14567 bump/update (ModelMultipleChoiceField: self.queryset.none() vs. [])

[Stephen Burrows]

http://code.djangoproject.com/ticket/14567
I recently updated my django trunk and noticed some changes to the test file
structure that made my previous patch for this issue invalid, so I went back
and made the necessary adjustments. I realize this isn't one of the more
controversial or interesting topics, as it's a fairly simple change, but I
was wondering if there's anything I should be working on to get this ready
for commit. I'd rather not have to continue making minor updates to make
sure the patch continues to match trunk.
Best,
Stephen Burrows

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bump/question for #13956

[Stephen Burrows]

As far as I know, the only thing still missing from the ticket is a
decision as to whether there need to be documentation changes for
simple tags and inclusion tags... if there need to be changes, I could
try working on them. I would just need to know.
Best,
Stephen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bump/question for #13956

[Stephen Burrows]

Thanks for the suggestion. I've added tests for the inclusion tags, so
now everything is being tested that I could think of - with the
exception of inclusion tags that have takes_context=True. Really,
though, they should act the same way from the tag's point of view. The
only difference is that if the first argument of the tag is not called
'context', the tag compilation function should raise a
TemplateSyntaxError. But that happens when the tag is registered, so
it seems like it ought to be tested elsewhere if it isn't already.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Patch: Indefinite args for simpletags and inclusion tags

[Stephen Burrows]

I went ahead and made a ticket with the patch. Thanks!
http://code.djangoproject.com/ticket/13956

--Stephen

On Jul 16, 1:25 pm, Tobias McNulty <tob...@caktusgroup.com> wrote:
> On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows <
>
> stephen.r.burr...@gmail.com> wrote:
> > Before posting the patch to django's ticketing system, I wanted to
> > check whether this would be a non-trivial patch and whether there
> > might be any good alternatives.
>
> Hard to tell without seeing the patch. :-)
>
> Could you stick it somewhere we can see it?  Personally I like to see them
> in Trac, since it comes with pretty colors.  If there isn't a ticket already
> out there for this I see no problem with creating one.  We can always close
> it if it gets rejected.
>
> Cheers
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> USA: +1 (919) 951-0052http://www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Patch: Indefinite args for simpletags and inclusion tags

[Stephen Burrows]

Hi,
I've patched django to allow indefinite args for simple tags and
inclusion tags. My impetus for doing so was as follows:

I have a project that registers inclusion template tags for methods on
objects in a registry. (http://github.com/melinath/pipettes/blob/
master/templatetags/pipettes.py) In order to correctly set the tag's
name (and provide other basic functionality in the future) I have to
wrap the method.

However, I have no way of knowing how many arguments the method will
have, and I don't want to restrict people who might register objects
to a certain number of arguments. So the wrapper should accept *args.

Unfortunately, django seems to purposely ignore the possibility of
*args in creating simple tags and inclusion tags, instead checking
only how many args and default args have been specified for the node's
function.

Before posting the patch to django's ticketing system, I wanted to
check whether this would be a non-trivial patch and whether there
might be any good alternatives.

Thanks!
--Stephen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.