date:20140909

The lead in to that post was "I think a lot of recent changes in the
language are harmful. Many common, short, clear, and concise words and
phrases are being replaces with long, vague, sterile versions. Not only in
the IT field, but everywhere." and then the poster went on to demonstrate
her case with the example of the logically misapplied term "person of
color" that is now popular amongst some minorities in the USA and probably
other western countries. In the context of the debate and in truthful fact
the person was being empathetic and not biased in any way. In fact she was
pointing out how the term itself is biased and making a very good point as
well. It was entirely germane to the speech concerns she raised and did not
attack any race or person at all. Unfortunately she hit one of the
politically correct landmines and those with an American-bias immediately
jumped on her for it quite inappropriately. The person who called out the
attempt to misapply the CoC on her also made this point.

I'm American but have lived around the world and currently reside in
Thailand. I have had many (actually almost every once they learn I'm
American) mixed and white S. Africans ask me if they lived in America could
they be considered African Americans as well. Interesting question. My
friends from Liberia, West Africa wonder in amazement at the terms
Americans use to describe black people who have clearly never been to
Africa. If one leaves their bias behind they will discover why many people
find these terms absurd and misapplied. None of this makes them racist.

So, yes, in the context of the debate that was going on the CoC was invoked
to kill speech neither intended to insult anyone and was clearly making a
point germane to the core issue of the discussion of concerns about
imposing American political correctness on the group. Turns out she was
right.

Could TPTB directed the conversation another way? Yes. But rather than use
reason, this person elected to use the threat of force against this person
who was espousing a concern in the interest of the community and making a
genuine attempt to make the community a better place.

-- Ben

On Wed, Sep 10, 2014 at 6:36 AM, James Bennett 
wrote:

> On Tue, Sep 9, 2014 at 6:25 PM, Benjamin Scherrey 
> wrote:
>
>> I really appreciate you for being the first person to directly
>> respond to this most critical issue in this debate. You are correct, this
>> incident is quite central to my point and concern. However, I have again
>> reviewed the group thread under discussion where the incident occurred and
>> found absolutely nothing that comes close to violating the CoC from the
>> person who was quite directly threatened to either shut up or be banned. It
>> doesn't get much clearer than that.
>>
>
> I went back and took a look at the thread. The comments were heated, but
> specifically I see things like referring to the terms "person of color" and
> "PoC" as "ridiculous", followed up by an example meant to mock the terms.
>
> Those are terms which are widely used by people both to self-identify and
> to talk about issues they face as a result of their racial background. If
> you believe that calling it "ridiculous" and mocking it is acceptable
> behavior, then I think the divide between your conception of "acceptable"
> and the community's definition of "acceptable" may be a bit too large for
> any meaningful discussion to take place.
>
> --
> 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/CAL13Cg8waRb5Nfq-1Nj1e%3DQbMwL7_VWfbpvNOtR-ap1jOk%3DCrQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Chief Systems Architect Proteus Technologies 
Chief Fan Biggest Fan Productions 
Personal blog where I am not your demographic
.

This email intended solely for those who have received it. If you have
received this email by accident - well lucky you!!

-- 
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

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Russell Keith-Magee

On Tue, Sep 9, 2014 at 11:40 PM, Thomas Leo  wrote:

> +1 for @Wim Feijen's rewording but...
>
> I think the wording of the Group description isn't the issue, my guess is
> that people who make the mistake of asking django-user's questions in the
> django-developers mailing list didn't read the description to begin with.
>
> > They are almost all from people whose first language is clearly not
> English,
>
> I haven't been following this mailing list for a particularly long time,
> but I
> can recall a number of cases where users were simply noobies looking for
> help,
> and didn't reading the description of this mailing list before asking their
> question.  Whether they are native English speakers or not, clearer wording
> would mitigate the issue for everyone.
>

Let me dispel this illusion for you.

If you go to Django's new ticket page:

https://code.djangoproject.com/newticket

You are greeted with the following text:

Please read this first:
Please don't report security issues here! Contact
secur...@djangoproject.com instead.

This text is in bold, and is a hyperlink to a page describing Django's
security processes in detail.

And yet, every couple of months, we get someone opening a ticket that
starts "I think I've found a security/DDOS issue in Django". The report
will be written in reasonably good english, so it isn't a language barrier
issue.

This is what I meant when I said you can't solve a social problem with
technology. Yes, we might be able to improve the number of errors by
improving the text, but at some level, it doesn't matter how large you make
the "PLEASE DON'T PUSH THIS BUTTON" sign, someone is going to push the
button. It is folly to believe that the problem is that we just haven't
found the right descriptive text.

Yours,
Russ Magee %-)

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

Re: Django 1.7 migrations and third-party imports


Done.

On 10 Sep 2014, at 10:45, Andrew Godwin wrote:


Looks good - make a pull request and I'll hit merge.

On Tue, Sep 9, 2014 at 3:05 PM, Greg Brown 
wrote:


How's this?


https://github.com/gregplaysguitar/django/commit/b4d486c80ff6bdfaec8f85e724b44ce5e74a5bb6



On Wednesday, 10 September 2014 09:42:52 UTC+12, Greg Brown wrote:


Hi all,

Thanks for the rapid responses! I wasn't aware that South imported 
the
custom fields, and I can definitely see why the 1.7 approach is 
better now.
I guess the fact that this never bit me in numerous past projects 
using

South shows it's not really a problem.

I agree that it'd be good to explicitly document this - I'll have a 
look

at that now.

Greg



On Wednesday, 10 September 2014 09:30:47 UTC+12, Andrew Godwin 
wrote:


Carl is correct, South serialized a dotted path to the field while
Django writes an import in, but it's the same thing in the end - 
the field
must keep existing. The advantage of the Django approach is that 
it's much

more obviously an import error now and happens immediately.

I'm happy to firm up the Django docs to reinforce that custom 
fields
must exist for the lifetime of their usage and beyond, if someone 
wants to

suggest the changes to make.

Also worth noting is that Django has the squashmigrations feature 
and
"replaces" stanza in migration files, meaning it's a lot easier to 
throw
away old migrations (ones with custom fields that are no longer 
used) and

start afresh now.

Andrew

On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer  
wrote:



Hi Greg,

On 09/09/2014 03:00 PM, Greg Brown wrote:

Moving over to the new migrations, I noticed that whenever I
create a migration involving a custom model field, it imports 
that

field
at the top of the migration. The South docs were always quite 
firm

about
not doing this sort of thing, in case the code changed in the 
future.

Is
this a design decision, i.e. we now expected to make sure imports 
in

our
migration files always work in the future? What are the reasons 
for
this? I can imagine this causing issues when refactoring old code 
for

example.


Andrew can correct me if I'm wrong, but I don't believe anything
significant has changed in this particular respect from South to 
Django
migrations. South serialized a dotted-path reference to custom 
field
classes in its frozen dict, whereas Django imports them in the 
migration
file, but the effect is identical; when the migration is run, the 
custom
field class is imported and used in the reconstructed model. In 
both
South and Django migrations, changing the import location of a 
custom
field will break past migrations (unless you fix them - and fixing 
them
is more obvious and straightforward in Django migrations) and 
changing
the behavior of a custom field class could change the behavior of 
a past

migration.

I don't believe that either South or Django has a feasible 
alternative,

since serializing/freezing arbitrary Python code is not workable.

When you say "the South docs were always quite firm about not 
doing this
sort of thing", you may be thinking of importing models directly 
into
your migration file. This is equally discouraged in both. Unlike 
custom

field classes, South and Django migrations do freeze (or actually
reconstruct, in the case of Django migrations) the structure of 
your
models (but not arbitrary methods; Python code again) at the time 
of the

migration, so if you import a model directly rather than using the
frozen version, it may not match your database tables.

Carl

--
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, 
send

an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at 
http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/

msgid/django-developers/540F70BA.4020404%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.



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

"Django developers" 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/6e4872f8-3b34-48a3-8721-4d4341299178%40googlegroups.com

.

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



--
You received this message because you are subscribed to a topic in the 
Google Groups "Django developers" group.
To

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Shai Berger

Ben,

Two points:

A) Your description of the threat-of-use-of-CoC incident, which appears to be
quite central to your argument (as a piece of evidence), is, as far as I can
see, inaccurate. The person who was threatened had started out reasonable, but
later made several disrespectful and prejudicial statements; it was only then
that the CoC was raised. Your repeated comments that the CoC was used to
silence legitimate opposition reflect quite badly on the people who brought the
CoC up in that discussion; I suggest that you reconsider those.

B) I think you are misinterpreting the intentions and functions of the CoC.
First, it is not formal law but a set of guidelines. It is not comprehensive
in any way, and not expected to be applied by machines; you made a logical
jump from "bad behavior outside Django fora may have consequences within" to
"telling a dirty joke to your friends will get you banned from conferences".
That is a serious leap of (lack of) faith. Second, the CoC is not intended to
transform the community -- rather, it expresses and explicates the standards
already in force. The same is true for the addition in PR 86, as has been
noted in its description.

Shai.

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

Re: Django 1.7 migrations and third-party imports

2014-09-09 Thread Andrew Godwin

Looks good - make a pull request and I'll hit merge.

On Tue, Sep 9, 2014 at 3:05 PM, Greg Brown 
wrote:

> How's this?
>
>
> https://github.com/gregplaysguitar/django/commit/b4d486c80ff6bdfaec8f85e724b44ce5e74a5bb6
>
>
>
> On Wednesday, 10 September 2014 09:42:52 UTC+12, Greg Brown wrote:
>>
>> Hi all,
>>
>> Thanks for the rapid responses! I wasn't aware that South imported the
>> custom fields, and I can definitely see why the 1.7 approach is better now.
>> I guess the fact that this never bit me in numerous past projects using
>> South shows it's not really a problem.
>>
>> I agree that it'd be good to explicitly document this - I'll have a look
>> at that now.
>>
>> Greg
>>
>>
>>
>> On Wednesday, 10 September 2014 09:30:47 UTC+12, Andrew Godwin wrote:
>>>
>>> Carl is correct, South serialized a dotted path to the field while
>>> Django writes an import in, but it's the same thing in the end - the field
>>> must keep existing. The advantage of the Django approach is that it's much
>>> more obviously an import error now and happens immediately.
>>>
>>> I'm happy to firm up the Django docs to reinforce that custom fields
>>> must exist for the lifetime of their usage and beyond, if someone wants to
>>> suggest the changes to make.
>>>
>>> Also worth noting is that Django has the squashmigrations feature and
>>> "replaces" stanza in migration files, meaning it's a lot easier to throw
>>> away old migrations (ones with custom fields that are no longer used) and
>>> start afresh now.
>>>
>>> Andrew
>>>
>>> On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer  wrote:
>>>
 Hi Greg,

 On 09/09/2014 03:00 PM, Greg Brown wrote:
 > Moving over to the new migrations, I noticed that whenever I
 > create a migration involving a custom model field, it imports that
 field
 > at the top of the migration. The South docs were always quite firm
 about
 > not doing this sort of thing, in case the code changed in the future.
 Is
 > this a design decision, i.e. we now expected to make sure imports in
 our
 > migration files always work in the future? What are the reasons for
 > this? I can imagine this causing issues when refactoring old code for
 > example.

 Andrew can correct me if I'm wrong, but I don't believe anything
 significant has changed in this particular respect from South to Django
 migrations. South serialized a dotted-path reference to custom field
 classes in its frozen dict, whereas Django imports them in the migration
 file, but the effect is identical; when the migration is run, the custom
 field class is imported and used in the reconstructed model. In both
 South and Django migrations, changing the import location of a custom
 field will break past migrations (unless you fix them - and fixing them
 is more obvious and straightforward in Django migrations) and changing
 the behavior of a custom field class could change the behavior of a past
 migration.

 I don't believe that either South or Django has a feasible alternative,
 since serializing/freezing arbitrary Python code is not workable.

 When you say "the South docs were always quite firm about not doing this
 sort of thing", you may be thinking of importing models directly into
 your migration file. This is equally discouraged in both. Unlike custom
 field classes, South and Django migrations do freeze (or actually
 reconstruct, in the case of Django migrations) the structure of your
 models (but not arbitrary methods; Python code again) at the time of the
 migration, so if you import a model directly rather than using the
 frozen version, it may not match your database tables.

 Carl

 --
 You received this message because you are subscribed to the Google
 Groups "Django developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-developers/540F70BA.4020404%40oddbird.net.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/6e4872f8-3b34-48a3-8721-4d4341299178%40googlegroups.com
>

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Audrey Roy Greenfeld



On Tuesday, September 9, 2014 3:07:57 PM UTC-7, Benjamin Scherrey wrote:
>
> James,
>
> I'm completely aware of the kind of situation you're describing in 
> some technical communities. I also don't find any evidence of it whatsoever 
> in ours, as I've pointed out repeatedly and have repeatedly asked for 
> evidence of by those who think a speech and behavior code is justifiable. 
> So far none has been forthcoming. You then ask "if you don't trust the 
> leaders of this community to handle things fairly and responsibly" well my 
> friend, that has already happened as I described before in this community. 
> So you seem focused on the theoretical while I'm far more interested in 
> what has actually happened.
>
>I'm curious to know - exactly what are the goals that people expect 
> from a speech and conduct code? Does anyone for this actually think that 
> such a policy is going to achieve these goals and do so without causing 
> more harm than good?
>

I actually do think that more good than harm can come from this :)

I checked the diff of #86. It is no different other than adding the DSF's 
opinion a bit more explicitly. It says "may affect," which is an opinion. 
There might be better ways to word it, and the CoC might need a bit of 
refactoring because #86 brings in some overlapping opinion, but the overall 
intent is good. 

As a longtime free speech advocate, I also see no formal restrictions 
imposed upon my rights by the specific words in #86.
 

> I believe, when thoughtfully considered and viewing the evidence that is 
> publicly available to all, that they must fail. Is that not a very simple 
> burden of evidence that any such policy should have to over come before 
> being adopted?
>

There is enough evidence. There have sadly been serious incidents in our 
community that have not been reported formally out of fear. Improving the 
CoC to better address the problem is certainly worthwhile. It may be 
impossible to eliminate serious incidents entirely, but at least we can try 
our best.

Audrey

 

>
> On Wed, Sep 10, 2014 at 2:51 AM, James Bennett  > wrote:
>
>> I have been involved in building and participating in and running 
>> technically-oriented groups for fifteen years. I've seen a lot of stuff.
>>
>> The most common problem pattern I have seen is the "I'm not touching you" 
>> game. To understand what this means, imagine parents driving a car, with 
>> two children in the back seat. Child A keeps poking Child B, so the parents 
>> instruct Child A to stop touching Child B. A few moments later, things 
>> resume, but now Child A says "I didn't touch him, the sleeve of my shirt 
>> touched him, you didn't say the sleeve of my shirt couldn't touch him". And 
>> away we go as Child A comes up with ever more convoluted technicalities to 
>> try to keep harassing Child B while still claiming it "wasn't against the 
>> rules".
>>
>> The "I'm not touching you" game is also a favorite of many types of 
>> people on the internet. Avoiding it requires policies which contain both 
>> affirmative and negative statements (i.e., lists of things 
>> encouraged/expected, lists of things forbidden) as well as a certain amount 
>> of discretion -- even, dare I say, a vague but probably large amount -- to 
>> be left in the hands of whichever person or persons will be responsible for 
>> enforcement, so that we don't end up playing "I'm not touching you" until 
>> the end of time. That little bit of discretion to step outside the stark 
>> technicalities and just bluntly deal with such people makes, in my 
>> experience at least, all the difference between a workable and an 
>> unworkable policy.
>>
>> So those are things that need to be in our CoC. If they make you 
>> uncomfortable, if you don't trust the leaders of this community to handle 
>> things fairly and responsibly, if you are chilled, silenced and terrified 
>> byt the idea that harassing behavior would result in ostracism from the 
>> Django community, then perhaps the Django community is simply not the place 
>> for you, because the kind of community we want to have and the kind of 
>> community you want to have may not be compatible.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAL13Cg9k1U6QA8dD3crFh%3D4JvpiDv19WLCUnOJ997DywAdjdCg%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Brenda W

Looks like this community reached consensus several posts ago -- unless 
Benjamin is boss of codes of conduct, it should be merged now.

On Wednesday, 10 September 2014 09:49:15 UTC+12, Benjamin Scherrey wrote:
>
> Aymeric,
>
> I'm afraid I don't understand your protest about my reply to you. You 
> very clearly took a position that the policy was effective because of how 
> rarely it has had to have been invoked. You didn't make any case whatsoever 
> to justify your belief that this was a causation relationship - in fact 
> there is no evidence to support this, and you neglected to consider the 
> dangers of a policy that enumerates banned speech and actions, which I have 
> provided evidence to support a concern. Your message was a direct reply to 
> mine, contrary to my argument, and so I replied. This is not painting you 
> as clueless (at least not my language, anyway) but simply replying to the 
> point you made.
>
>Next you then make the personal judgement, again without any basis, 
> that I am irrational and not reading what other people have written on this 
> topic. Well I reject that completely. Not only have I read every posting on 
> this topic carefully, you'll see I've also researched the history of both 
> django group archives and scoured the internet for information supporting 
> both sides of this debate. Your reply, however, seems to suggest you really 
> haven't bothered to read the concerns about a speech code that I have 
> posted because it, as do almost all the other replies, completely ignores 
> these concerns despite actual evidence supporting them. I suggest you 
> follow your own advice.
>
> -- Ben
>
> On Wed, Sep 10, 2014 at 3:02 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Benjamin,
>>
>> Please read my email again. I did not take a side in the debate.
>>
>> I didn’t say anything about the two PRs or your arguments.
>>
>> I didn’t support your position but I didn’t reject it either.
>>
>> Please realize that your answer expresses prejudice about my beliefs and 
>> that it paints me as a clueless person for no good reason. It attempts to 
>> force me to pick a side, and rather aggressively, while I’m not ready to do 
>> so in public.
>>
>> Please consider that I’m unfamiliar with the American cultural standards 
>> that underlie this entire debate and uncomfortable with participating as a 
>> non-native speaker, as the topic is too sensitive to allow for 
>> approximative vocabulary.
>>
>> That said, may I suggest kindly that you cool down a bit and read what 
>> others write?
>>
>> -- 
>> Aymeric.
>>
>>
>>  
>> On 9 sept. 2014, at 21:28, Benjamin Scherrey > > wrote:
>>
>> Aymeric,
>>
>> You don't believe that one should also consider how it is used? I 
>> have already documented that the single ever documented threatened use of 
>> the existing code of conduct was not to protect anyone from harassment but, 
>> in fact, was used to stifle someone's thoughtful and reasoned argument and 
>> end debate on a point. Exactly the kind of thing that I commonly see in the 
>> rest of the world where such speech and conduct codes are applied. They 
>> inevitably lead to this and I find that coercive and destructive. Evil in 
>> the name of good is twice as evil.
>>
>> I will also note that I have made several direct assertions about the 
>> positive aspects and negative aspects of certain policies. The sudden 
>> influx of people speaking in support for a speech and conduct code that 
>> enumerates forbidden activities have all chosen not to respond to any of 
>> these assertions with reasoned arguments or provide any assertions of their 
>> own backed up by evidence. None. Zero. I think that speaks very much 
>> towards the quality of their arguments and the resulting policies if their 
>> preferences are chosen. Sadly, I also anticipated this when I replied to 
>> Kevin's latest post asking for those who supported the speech code to 
>> respond to my concerns directly because the usual tactic by people wishing 
>> to impose such things is to argue around the subject rather than address 
>> the real documented problems with it. Alex gets partial credit for at least 
>> giving some specific support (the Ada group's recommendation) for why he 
>> wants it but no one has bothered to address the clear and present 
>> documented dangers of such a thing as I have argued.
>>
>> Again, getting back to the subject of the two PRs, 84 is fine but 86 
>> is way out of line because you've then imposed a speech and conduct code on 
>> the entire universe without any context of having anything to do with 
>> Django. Nothing good can come of this.
>>
>> -- Ben
>>
>> On Wed, Sep 10, 2014 at 2:12 AM, Aymeric Augustin <
>> aymeric@polytechnique.org > wrote:
>>
>>> On 9 sept. 2014, at 19:54, Benjamin Scherrey >> > wrote:
>>>
>>> > So far we have exactly one documented example and TPTB took it 
>>> seriously

Re: Two proposals for the Django Code of Conduct.

Kate,

What you did there is a perfect example of how to enforce an
affirmative inclusive conduct policy. My reply was not intended (and
hopefully not perceived as such) to belittle him but rather to clarify the
record of what my position was and the facts of my effort to support them.
I will attempt to do so more generally going forward and hope that we can
all concentrate on the points raised rather than personalities involved.

Thanx,

 -- Ben

On Wed, Sep 10, 2014 at 4:54 AM, kate heddleston 
wrote:

> Ben,
>
> Aymeric has the right to opt out of this conversation at anytime if he is
> uncomfortable. You may continue to share your opinions on the topic to the
> group as a whole but there is no need to directly address him if he does
> not want that.
>
> Kate
>

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

Re: Two proposals for the Django Code of Conduct.

Reinout,

Thanks for your thoughtful reply. I agree with and understand the
intent. Unfortunately those with said intent seem to have elected to ignore
the law of unintended consequences which I have attempted to spell out and
demonstrate. Such policies and intentions aren't always practical to
enforce and do more harm than good - making bad law. My experience is that
a policy of affirmative inclusion accomplishes everything that can be
accomplished without the negative side effects.

best,

  -- Ben

On Wed, Sep 10, 2014 at 4:56 AM, Reinout van Rees 
wrote:

> On 08-09-14 09:16, Benjamin Scherrey wrote:
>
>>
>> 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:
>>
>
> You mention a number of things you aren't allowed to ever have done
> somewhere else in your life. "He who's innocent is allowed to throw the
> first stone", you might say.
>
> What is the intention of the change-in-wording? My guess is as follows. I
> remember reading some harrasment blog post two years ago. In which someone
> blatantly misbehaved in a bar during a conference. Nothing was done from
> the conference's side because it was after conference hours in a
> non-at-the-conference bar and not at a conference-sponsored event.
>
> To my eyes, the change of wording in the pull request only *intends* to
> put a stop to the 
> it-was-in-a-random-bar-and-not-at-the-official-django-conference
> excuses.
>
>
> Reading the entire thread, it doesn't seem like the intention is to start
> a full-out thought police. In your opinion, wouldn't this mailinglist
> thread be enough of a safeguard against unwanted use of the pull request?
>
>
> Reinout
>
> --
> Reinout van Rees  http://reinout.vanrees.org/
> rein...@vanrees.org   http://www.nelen-schuurmans.nl/
> "Learning history by destroying artifacts is a time-honored atrocity"
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/lunt3a%24ipf%241%40ger.gmane.org.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Chief Systems Architect Proteus Technologies 
Chief Fan Biggest Fan Productions 
Personal blog where I am not your demographic
.

This email intended solely for those who have received it. If you have
received this email by accident - well lucky you!!

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

Re: Two proposals for the Django Code of Conduct.

James,

I'm completely aware of the kind of situation you're describing in some
technical communities. I also don't find any evidence of it whatsoever in
ours, as I've pointed out repeatedly and have repeatedly asked for evidence
of by those who think a speech and behavior code is justifiable. So far
none has been forthcoming. You then ask "if you don't trust the leaders of
this community to handle things fairly and responsibly" well my friend,
that has already happened as I described before in this community. So you
seem focused on the theoretical while I'm far more interested in what has
actually happened.

   I'm curious to know - exactly what are the goals that people expect from
a speech and conduct code? Does anyone for this actually think that such a
policy is going to achieve these goals and do so without causing more harm
than good? I believe, when thoughtfully considered and viewing the evidence
that is publicly available to all, that they must fail. Is that not a very
simple burden of evidence that any such policy should have to over come
before being adopted? I should hope so and, thus far, all those supporting
have completely ignored the downside and have provided no evidence
supporting the need for one in our community. Other communities, perhaps,
but then I don't participate in those. I like the think that the Django
community, far before the existence of any such policy and continuing
today, is already beyond the "I'm not touching you game". Don't break what
doesn't need fixing. We really should apply a "first do no harm" test
against any such policies designed to control people's behavior and speech
- especially when we have the hubris to then attempt to impose such
policies outside the context of Django which is exactly what the 2nd PR
does.

   This last bit, however, "if you are chilled, silenced and terrified by
the idea that harassing behavior would result in ostracism from the Django
community" I'm afraid is personally insulting and distasteful. No one,
especially me, has made any argument of the sort and it's an attempt to say
"if you're against the code then you must be for that kind of behavior". My
position is, as I'm sure people are tired of by now, very well documented.
It's not the intention of the policy that concerns me, it is the (again
documented) abuse of such that I have a very big problem with. And you seem
to be perfectly willing to drop myself, and others who are very much
invested in Django from the community for disagreeing and I find that
rather sad. I expect you have no idea who I am but I have followed you for
some time and my opinion of you has, thus far, been much higher than that.

thanx,

  -- Ben Scherrey

On Wed, Sep 10, 2014 at 2:51 AM, James Bennett 
wrote:

> I have been involved in building and participating in and running
> technically-oriented groups for fifteen years. I've seen a lot of stuff.
>
> The most common problem pattern I have seen is the "I'm not touching you"
> game. To understand what this means, imagine parents driving a car, with
> two children in the back seat. Child A keeps poking Child B, so the parents
> instruct Child A to stop touching Child B. A few moments later, things
> resume, but now Child A says "I didn't touch him, the sleeve of my shirt
> touched him, you didn't say the sleeve of my shirt couldn't touch him". And
> away we go as Child A comes up with ever more convoluted technicalities to
> try to keep harassing Child B while still claiming it "wasn't against the
> rules".
>
> The "I'm not touching you" game is also a favorite of many types of people
> on the internet. Avoiding it requires policies which contain both
> affirmative and negative statements (i.e., lists of things
> encouraged/expected, lists of things forbidden) as well as a certain amount
> of discretion -- even, dare I say, a vague but probably large amount -- to
> be left in the hands of whichever person or persons will be responsible for
> enforcement, so that we don't end up playing "I'm not touching you" until
> the end of time. That little bit of discretion to step outside the stark
> technicalities and just bluntly deal with such people makes, in my
> experience at least, all the difference between a workable and an
> unworkable policy.
>
> So those are things that need to be in our CoC. If they make you
> uncomfortable, if you don't trust the leaders of this community to handle
> things fairly and responsibly, if you are chilled, silenced and terrified
> byt the idea that harassing behavior would result in ostracism from the
> Django community, then perhaps the Django community is simply not the place
> for you, because the kind of community we want to have and the kind of
> community you want to have may not be compatible.
>
> --
> 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

Re: Django 1.7 migrations and third-party imports

How's this?

https://github.com/gregplaysguitar/django/commit/b4d486c80ff6bdfaec8f85e724b44ce5e74a5bb6



On Wednesday, 10 September 2014 09:42:52 UTC+12, Greg Brown wrote:
>
> Hi all,
>
> Thanks for the rapid responses! I wasn't aware that South imported the 
> custom fields, and I can definitely see why the 1.7 approach is better now. 
> I guess the fact that this never bit me in numerous past projects using 
> South shows it's not really a problem.
>
> I agree that it'd be good to explicitly document this - I'll have a look 
> at that now.
>
> Greg
>
>
>
> On Wednesday, 10 September 2014 09:30:47 UTC+12, Andrew Godwin wrote:
>>
>> Carl is correct, South serialized a dotted path to the field while Django 
>> writes an import in, but it's the same thing in the end - the field must 
>> keep existing. The advantage of the Django approach is that it's much more 
>> obviously an import error now and happens immediately.
>>
>> I'm happy to firm up the Django docs to reinforce that custom fields must 
>> exist for the lifetime of their usage and beyond, if someone wants to 
>> suggest the changes to make.
>>
>> Also worth noting is that Django has the squashmigrations feature and 
>> "replaces" stanza in migration files, meaning it's a lot easier to throw 
>> away old migrations (ones with custom fields that are no longer used) and 
>> start afresh now.
>>
>> Andrew
>>
>> On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer  wrote:
>>
>>> Hi Greg,
>>>
>>> On 09/09/2014 03:00 PM, Greg Brown wrote:
>>> > Moving over to the new migrations, I noticed that whenever I
>>> > create a migration involving a custom model field, it imports that 
>>> field
>>> > at the top of the migration. The South docs were always quite firm 
>>> about
>>> > not doing this sort of thing, in case the code changed in the future. 
>>> Is
>>> > this a design decision, i.e. we now expected to make sure imports in 
>>> our
>>> > migration files always work in the future? What are the reasons for
>>> > this? I can imagine this causing issues when refactoring old code for
>>> > example.
>>>
>>> Andrew can correct me if I'm wrong, but I don't believe anything
>>> significant has changed in this particular respect from South to Django
>>> migrations. South serialized a dotted-path reference to custom field
>>> classes in its frozen dict, whereas Django imports them in the migration
>>> file, but the effect is identical; when the migration is run, the custom
>>> field class is imported and used in the reconstructed model. In both
>>> South and Django migrations, changing the import location of a custom
>>> field will break past migrations (unless you fix them - and fixing them
>>> is more obvious and straightforward in Django migrations) and changing
>>> the behavior of a custom field class could change the behavior of a past
>>> migration.
>>>
>>> I don't believe that either South or Django has a feasible alternative,
>>> since serializing/freezing arbitrary Python code is not workable.
>>>
>>> When you say "the South docs were always quite firm about not doing this
>>> sort of thing", you may be thinking of importing models directly into
>>> your migration file. This is equally discouraged in both. Unlike custom
>>> field classes, South and Django migrations do freeze (or actually
>>> reconstruct, in the case of Django migrations) the structure of your
>>> models (but not arbitrary methods; Python code again) at the time of the
>>> migration, so if you import a model directly rather than using the
>>> frozen version, it may not match your database tables.
>>>
>>> Carl
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/540F70BA.4020404%40oddbird.net
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/6e4872f8-3b34-48a3-8721-4d4341299178%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Reinout van Rees


On 08-09-14 09:16, Benjamin Scherrey wrote:


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:


You mention a number of things you aren't allowed to ever have done 
somewhere else in your life. "He who's innocent is allowed to throw the 
first stone", you might say.


What is the intention of the change-in-wording? My guess is as follows. 
I remember reading some harrasment blog post two years ago. In which 
someone blatantly misbehaved in a bar during a conference. Nothing was 
done from the conference's side because it was after conference hours in 
a non-at-the-conference bar and not at a conference-sponsored event.


To my eyes, the change of wording in the pull request only *intends* to 
put a stop to the 
it-was-in-a-random-bar-and-not-at-the-official-django-conference excuses.



Reading the entire thread, it doesn't seem like the intention is to 
start a full-out thought police. In your opinion, wouldn't this 
mailinglist thread be enough of a safeguard against unwanted use of the 
pull request?



Reinout

--
Reinout van Rees  http://reinout.vanrees.org/
rein...@vanrees.org   http://www.nelen-schuurmans.nl/
"Learning history by destroying artifacts is a time-honored atrocity"

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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/lunt3a%24ipf%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread kate heddleston

Ben,

Aymeric has the right to opt out of this conversation at anytime if he is 
uncomfortable. You may continue to share your opinions on the topic to the 
group as a whole but there is no need to directly address him if he does 
not want that.

Kate

On Tuesday, September 9, 2014 5:49:15 PM UTC-4, Benjamin Scherrey wrote:
>
> Aymeric,
>
> I'm afraid I don't understand your protest about my reply to you. You 
> very clearly took a position that the policy was effective because of how 
> rarely it has had to have been invoked. You didn't make any case whatsoever 
> to justify your belief that this was a causation relationship - in fact 
> there is no evidence to support this, and you neglected to consider the 
> dangers of a policy that enumerates banned speech and actions, which I have 
> provided evidence to support a concern. Your message was a direct reply to 
> mine, contrary to my argument, and so I replied. This is not painting you 
> as clueless (at least not my language, anyway) but simply replying to the 
> point you made.
>
>Next you then make the personal judgement, again without any basis, 
> that I am irrational and not reading what other people have written on this 
> topic. Well I reject that completely. Not only have I read every posting on 
> this topic carefully, you'll see I've also researched the history of both 
> django group archives and scoured the internet for information supporting 
> both sides of this debate. Your reply, however, seems to suggest you really 
> haven't bothered to read the concerns about a speech code that I have 
> posted because it, as do almost all the other replies, completely ignores 
> these concerns despite actual evidence supporting them. I suggest you 
> follow your own advice.
>
> -- Ben
>
> On Wed, Sep 10, 2014 at 3:02 AM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Benjamin,
>>
>> Please read my email again. I did not take a side in the debate.
>>
>> I didn’t say anything about the two PRs or your arguments.
>>
>> I didn’t support your position but I didn’t reject it either.
>>
>> Please realize that your answer expresses prejudice about my beliefs and 
>> that it paints me as a clueless person for no good reason. It attempts to 
>> force me to pick a side, and rather aggressively, while I’m not ready to do 
>> so in public.
>>
>> Please consider that I’m unfamiliar with the American cultural standards 
>> that underlie this entire debate and uncomfortable with participating as a 
>> non-native speaker, as the topic is too sensitive to allow for 
>> approximative vocabulary.
>>
>> That said, may I suggest kindly that you cool down a bit and read what 
>> others write?
>>
>> -- 
>> Aymeric.
>>
>>
>>  
>> On 9 sept. 2014, at 21:28, Benjamin Scherrey > > wrote:
>>
>> Aymeric,
>>
>> You don't believe that one should also consider how it is used? I 
>> have already documented that the single ever documented threatened use of 
>> the existing code of conduct was not to protect anyone from harassment but, 
>> in fact, was used to stifle someone's thoughtful and reasoned argument and 
>> end debate on a point. Exactly the kind of thing that I commonly see in the 
>> rest of the world where such speech and conduct codes are applied. They 
>> inevitably lead to this and I find that coercive and destructive. Evil in 
>> the name of good is twice as evil.
>>
>> I will also note that I have made several direct assertions about the 
>> positive aspects and negative aspects of certain policies. The sudden 
>> influx of people speaking in support for a speech and conduct code that 
>> enumerates forbidden activities have all chosen not to respond to any of 
>> these assertions with reasoned arguments or provide any assertions of their 
>> own backed up by evidence. None. Zero. I think that speaks very much 
>> towards the quality of their arguments and the resulting policies if their 
>> preferences are chosen. Sadly, I also anticipated this when I replied to 
>> Kevin's latest post asking for those who supported the speech code to 
>> respond to my concerns directly because the usual tactic by people wishing 
>> to impose such things is to argue around the subject rather than address 
>> the real documented problems with it. Alex gets partial credit for at least 
>> giving some specific support (the Ada group's recommendation) for why he 
>> wants it but no one has bothered to address the clear and present 
>> documented dangers of such a thing as I have argued.
>>
>> Again, getting back to the subject of the two PRs, 84 is fine but 86 
>> is way out of line because you've then imposed a speech and conduct code on 
>> the entire universe without any context of having anything to do with 
>> Django. Nothing good can come of this.
>>
>> -- Ben
>>
>> On Wed, Sep 10, 2014 at 2:12 AM, Aymeric Augustin <
>> aymeric@polytechnique.org > wrote:
>>
>>> On 9 sept. 2014, at 19:54, Benjamin Scherrey

Re: Two proposals for the Django Code of Conduct.

Aymeric,

I'm afraid I don't understand your protest about my reply to you. You
very clearly took a position that the policy was effective because of how
rarely it has had to have been invoked. You didn't make any case whatsoever
to justify your belief that this was a causation relationship - in fact
there is no evidence to support this, and you neglected to consider the
dangers of a policy that enumerates banned speech and actions, which I have
provided evidence to support a concern. Your message was a direct reply to
mine, contrary to my argument, and so I replied. This is not painting you
as clueless (at least not my language, anyway) but simply replying to the
point you made.

   Next you then make the personal judgement, again without any basis, that
I am irrational and not reading what other people have written on this
topic. Well I reject that completely. Not only have I read every posting on
this topic carefully, you'll see I've also researched the history of both
django group archives and scoured the internet for information supporting
both sides of this debate. Your reply, however, seems to suggest you really
haven't bothered to read the concerns about a speech code that I have
posted because it, as do almost all the other replies, completely ignores
these concerns despite actual evidence supporting them. I suggest you
follow your own advice.

-- Ben

On Wed, Sep 10, 2014 at 3:02 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Benjamin,
>
> Please read my email again. I did not take a side in the debate.
>
> I didn’t say anything about the two PRs or your arguments.
>
> I didn’t support your position but I didn’t reject it either.
>
> Please realize that your answer expresses prejudice about my beliefs and
> that it paints me as a clueless person for no good reason. It attempts to
> force me to pick a side, and rather aggressively, while I’m not ready to do
> so in public.
>
> Please consider that I’m unfamiliar with the American cultural standards
> that underlie this entire debate and uncomfortable with participating as a
> non-native speaker, as the topic is too sensitive to allow for
> approximative vocabulary.
>
> That said, may I suggest kindly that you cool down a bit and read what
> others write?
>
> --
> Aymeric.
>
>
>
> On 9 sept. 2014, at 21:28, Benjamin Scherrey  wrote:
>
> Aymeric,
>
> You don't believe that one should also consider how it is used? I have
> already documented that the single ever documented threatened use of the
> existing code of conduct was not to protect anyone from harassment but, in
> fact, was used to stifle someone's thoughtful and reasoned argument and end
> debate on a point. Exactly the kind of thing that I commonly see in the
> rest of the world where such speech and conduct codes are applied. They
> inevitably lead to this and I find that coercive and destructive. Evil in
> the name of good is twice as evil.
>
> I will also note that I have made several direct assertions about the
> positive aspects and negative aspects of certain policies. The sudden
> influx of people speaking in support for a speech and conduct code that
> enumerates forbidden activities have all chosen not to respond to any of
> these assertions with reasoned arguments or provide any assertions of their
> own backed up by evidence. None. Zero. I think that speaks very much
> towards the quality of their arguments and the resulting policies if their
> preferences are chosen. Sadly, I also anticipated this when I replied to
> Kevin's latest post asking for those who supported the speech code to
> respond to my concerns directly because the usual tactic by people wishing
> to impose such things is to argue around the subject rather than address
> the real documented problems with it. Alex gets partial credit for at least
> giving some specific support (the Ada group's recommendation) for why he
> wants it but no one has bothered to address the clear and present
> documented dangers of such a thing as I have argued.
>
> Again, getting back to the subject of the two PRs, 84 is fine but 86
> is way out of line because you've then imposed a speech and conduct code on
> the entire universe without any context of having anything to do with
> Django. Nothing good can come of this.
>
> -- Ben
>
> On Wed, Sep 10, 2014 at 2:12 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> On 9 sept. 2014, at 19:54, Benjamin Scherrey 
>> wrote:
>>
>> > So far we have exactly one documented example and TPTB took it
>> seriously right away. To me, this hardly justifies any need for an explicit
>> "anti-harassment" policy.
>>
>> I believe the success of the code of conduct is measured by how rarely it
>> is needed.
>>
>> If it never needs to be brought up, then it has achieved its goal.
>>
>> So thanks for confirming that it works well :-)
>>
>> --
>> Aymeric.
>>
>> --
>> You received this message because you

Re: Django 1.7 migrations and third-party imports

Hi all,

Thanks for the rapid responses! I wasn't aware that South imported the 
custom fields, and I can definitely see why the 1.7 approach is better now. 
I guess the fact that this never bit me in numerous past projects using 
South shows it's not really a problem.

I agree that it'd be good to explicitly document this - I'll have a look at 
that now.

Greg



On Wednesday, 10 September 2014 09:30:47 UTC+12, Andrew Godwin wrote:
>
> Carl is correct, South serialized a dotted path to the field while Django 
> writes an import in, but it's the same thing in the end - the field must 
> keep existing. The advantage of the Django approach is that it's much more 
> obviously an import error now and happens immediately.
>
> I'm happy to firm up the Django docs to reinforce that custom fields must 
> exist for the lifetime of their usage and beyond, if someone wants to 
> suggest the changes to make.
>
> Also worth noting is that Django has the squashmigrations feature and 
> "replaces" stanza in migration files, meaning it's a lot easier to throw 
> away old migrations (ones with custom fields that are no longer used) and 
> start afresh now.
>
> Andrew
>
> On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer  > wrote:
>
>> Hi Greg,
>>
>> On 09/09/2014 03:00 PM, Greg Brown wrote:
>> > Moving over to the new migrations, I noticed that whenever I
>> > create a migration involving a custom model field, it imports that field
>> > at the top of the migration. The South docs were always quite firm about
>> > not doing this sort of thing, in case the code changed in the future. Is
>> > this a design decision, i.e. we now expected to make sure imports in our
>> > migration files always work in the future? What are the reasons for
>> > this? I can imagine this causing issues when refactoring old code for
>> > example.
>>
>> Andrew can correct me if I'm wrong, but I don't believe anything
>> significant has changed in this particular respect from South to Django
>> migrations. South serialized a dotted-path reference to custom field
>> classes in its frozen dict, whereas Django imports them in the migration
>> file, but the effect is identical; when the migration is run, the custom
>> field class is imported and used in the reconstructed model. In both
>> South and Django migrations, changing the import location of a custom
>> field will break past migrations (unless you fix them - and fixing them
>> is more obvious and straightforward in Django migrations) and changing
>> the behavior of a custom field class could change the behavior of a past
>> migration.
>>
>> I don't believe that either South or Django has a feasible alternative,
>> since serializing/freezing arbitrary Python code is not workable.
>>
>> When you say "the South docs were always quite firm about not doing this
>> sort of thing", you may be thinking of importing models directly into
>> your migration file. This is equally discouraged in both. Unlike custom
>> field classes, South and Django migrations do freeze (or actually
>> reconstruct, in the case of Django migrations) the structure of your
>> models (but not arbitrary methods; Python code again) at the time of the
>> migration, so if you import a model directly rather than using the
>> frozen version, it may not match your database tables.
>>
>> Carl
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/540F70BA.4020404%40oddbird.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/76e7f5e9-3a79-48fe-af5f-83db2029b84e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7 migrations and third-party imports

2014-09-09 Thread Andrew Godwin

Carl is correct, South serialized a dotted path to the field while Django
writes an import in, but it's the same thing in the end - the field must
keep existing. The advantage of the Django approach is that it's much more
obviously an import error now and happens immediately.

I'm happy to firm up the Django docs to reinforce that custom fields must
exist for the lifetime of their usage and beyond, if someone wants to
suggest the changes to make.

Also worth noting is that Django has the squashmigrations feature and
"replaces" stanza in migration files, meaning it's a lot easier to throw
away old migrations (ones with custom fields that are no longer used) and
start afresh now.

Andrew

On Tue, Sep 9, 2014 at 2:27 PM, Carl Meyer  wrote:

> Hi Greg,
>
> On 09/09/2014 03:00 PM, Greg Brown wrote:
> > Moving over to the new migrations, I noticed that whenever I
> > create a migration involving a custom model field, it imports that field
> > at the top of the migration. The South docs were always quite firm about
> > not doing this sort of thing, in case the code changed in the future. Is
> > this a design decision, i.e. we now expected to make sure imports in our
> > migration files always work in the future? What are the reasons for
> > this? I can imagine this causing issues when refactoring old code for
> > example.
>
> Andrew can correct me if I'm wrong, but I don't believe anything
> significant has changed in this particular respect from South to Django
> migrations. South serialized a dotted-path reference to custom field
> classes in its frozen dict, whereas Django imports them in the migration
> file, but the effect is identical; when the migration is run, the custom
> field class is imported and used in the reconstructed model. In both
> South and Django migrations, changing the import location of a custom
> field will break past migrations (unless you fix them - and fixing them
> is more obvious and straightforward in Django migrations) and changing
> the behavior of a custom field class could change the behavior of a past
> migration.
>
> I don't believe that either South or Django has a feasible alternative,
> since serializing/freezing arbitrary Python code is not workable.
>
> When you say "the South docs were always quite firm about not doing this
> sort of thing", you may be thinking of importing models directly into
> your migration file. This is equally discouraged in both. Unlike custom
> field classes, South and Django migrations do freeze (or actually
> reconstruct, in the case of Django migrations) the structure of your
> models (but not arbitrary methods; Python code again) at the time of the
> migration, so if you import a model directly rather than using the
> frozen version, it may not match your database tables.
>
> Carl
>
> --
> 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/540F70BA.4020404%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Django 1.7 migrations and third-party imports

2014-09-09 Thread Carl Meyer

Hi Greg,

On 09/09/2014 03:00 PM, Greg Brown wrote:
> Moving over to the new migrations, I noticed that whenever I
> create a migration involving a custom model field, it imports that field
> at the top of the migration. The South docs were always quite firm about
> not doing this sort of thing, in case the code changed in the future. Is
> this a design decision, i.e. we now expected to make sure imports in our
> migration files always work in the future? What are the reasons for
> this? I can imagine this causing issues when refactoring old code for
> example.

Andrew can correct me if I'm wrong, but I don't believe anything
significant has changed in this particular respect from South to Django
migrations. South serialized a dotted-path reference to custom field
classes in its frozen dict, whereas Django imports them in the migration
file, but the effect is identical; when the migration is run, the custom
field class is imported and used in the reconstructed model. In both
South and Django migrations, changing the import location of a custom
field will break past migrations (unless you fix them - and fixing them
is more obvious and straightforward in Django migrations) and changing
the behavior of a custom field class could change the behavior of a past
migration.

I don't believe that either South or Django has a feasible alternative,
since serializing/freezing arbitrary Python code is not workable.

When you say "the South docs were always quite firm about not doing this
sort of thing", you may be thinking of importing models directly into
your migration file. This is equally discouraged in both. Unlike custom
field classes, South and Django migrations do freeze (or actually
reconstruct, in the case of Django migrations) the structure of your
models (but not arbitrary methods; Python code again) at the time of the
migration, so if you import a model directly rather than using the
frozen version, it may not match your database tables.

Carl

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

Re: Django 1.7 migrations and third-party imports

2014-09-09 Thread Tim Graham

Questions related to design decisions are a valid topic for 
django-developers.

In this case, please see this documentation: 
https://docs.djangoproject.com/en/dev/topics/migrations/#historical-models

Perhaps Andrew may want to explain the design decision further.

On Tuesday, September 9, 2014 5:11:27 PM UTC-4, Daniele Procida wrote:
>
> On Tue, Sep 9, 2014, Greg Brown  
> wrote: 
>
> >Moving over to the new migrations, I noticed that whenever I 
> >create a migration involving a custom model field, it imports that field 
> >at the top of the migration. The South docs were always quite firm about 
> >not doing this sort of thing, in case the code changed in the future. Is 
> >this a design decision, i.e. we now expected to make sure imports in our 
> >migration files always work in the future? 
>
> Hi Greg, 
>
> You'll get answers to your questions on the django-users email list, <
> django-d...@googlegroups.com > - the web interface is <
> https://groups.google.com/forum/#!forum/django-users>. 
>
> The list you've posted to is django-developers, an email list is for the 
> discussion of the development of Django itself. 
>
> You might also find helpful the #django IRC channel on irc.freenode.net. 
>
> 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/79f5deae-0bca-4f1f-a95f-85653911e5e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7 migrations and third-party imports

On Tue, Sep 9, 2014, Greg Brown  wrote:

>Moving over to the new migrations, I noticed that whenever I
>create a migration involving a custom model field, it imports that field
>at the top of the migration. The South docs were always quite firm about
>not doing this sort of thing, in case the code changed in the future. Is
>this a design decision, i.e. we now expected to make sure imports in our
>migration files always work in the future?

Hi Greg,

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

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

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Wim Feijen

Hi Daniel,

An idea we spoke about earlier in this tread is to rename the group to 
Django Contributors, and the slug (and url) to remain django-developers in 
order to preserve links.

Wim

On Tuesday, 9 September 2014 22:04:30 UTC+2, Daniel Pyrathon wrote:
>
> Hi,
>
> I think that changing the name the community on google will create many 
> broken links, this will be a huge loss.
> What we can do instead, is create 2 domains (or subdomains) such as 
> core-development.djangoproject.com and community.djangoproject.com that 
> will serve as the official URLs to publicise on blogs, official sites and 
> IRC. These ULRs will redirect to the related google forums.
>
> Dan
>
> On Tuesday, September 9, 2014, Erik Romijn  > wrote:
>
>> I think it would also be a great improvement if we all adopted a standard 
>> response for these kind of mails - because no matter what we do, some will 
>> still end up here.
>>
>> Almost entirely based on Daniele's previous responses, how about we use:
>>
>> > The best place to get answers to your questions is the django-users 
>> email list,  - the web interface is <
>> https://groups.google.com/forum/#!forum/django-users>.
>> >
>> > The list you've posted to is django-developers, an email list is for 
>> the discussion of the development of Django itself.
>> >
>> > You might also find helpful the #django IRC channel on irc.freenode.net
>> .
>> >
>> > I hope that helps,
>>
>> This focuses first on helping them get to the right place, with easily 
>> readable language, and then explains their error in a friendly way. In the 
>> past, we've occasionally sent somewhat more harsh replies, focusing more on 
>> how they did something wrong. Although I'm sure such replies were 
>> absolutely sent with the best intentions, it's not a pleasant first 
>> experience.
>>
>> Not sure what the best place is to keep this template easily accessible 
>> for anyone though. The wiki might be the most suitable.
>>
>> Erik
>>
>> --
>> 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/07EC2CEB-A0AC-4624-874C-6D8FBD9D594C%40solidlinks.nl
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> *
>
> PirosB3
>
> https://github.com/PirosB3
>
>

-- 
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/8ce347c2-79f0-4615-a684-9031fabaa48c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.7 migrations and third-party imports

Hi all,

Moving over to the new migrations, I noticed that whenever I
create a migration involving a custom model field, it imports that field
at the top of the migration. The South docs were always quite firm about
not doing this sort of thing, in case the code changed in the future. Is
this a design decision, i.e. we now expected to make sure imports in our
migration files always work in the future? What are the reasons for
this? I can imagine this causing issues when refactoring old code for
example.

Thanks,
Greg

-- 
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/46209b0d-6e9e-4e67-a510-90fcc2bda3a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Tim Graham

Test failures are fixed with mysqlclient 1.3.3. I believe we can now move 
the discussion of the implementation of this to the 
ticket: https://code.djangoproject.com/ticket/23446

There are some tickets about pymysql (below), but I have some reservations 
about officially supporting more than one MySQL connector since our 
buildbot would presumably need to test all of them.

https://code.djangoproject.com/ticket/20542
https://code.djangoproject.com/ticket/22391

On Tuesday, September 9, 2014 3:32:47 PM UTC-4, Corey Farwell wrote:
>
> It is a valid concern. That said, I'd rather the documentation recommend a 
> GPL, Python 3+2, working MySQL connector over a GPL, Python 2, partially 
> broken MySQL connector.
>
> On Tuesday, September 9, 2014 3:21:08 PM UTC-4, Daniel Sears wrote:
>>
>> Aside from the technical issues, there are the licensing issues. The 
>> Django community strongly prefers BSD-style licensing and both mysqldb and 
>> MySQL Connector/Python use GPL licenses. For an e-mail thread which 
>> addresses these GPL issues, see
>>
>>
>> https://groups.google.com/forum/#!msg/django-developers/8r_RVmUe5ys/09lCwJl-L1kJ
>>
>> PyMySQL does appear to have a BSD-like license.
>>
>> --Dan
>>
>>
>> On Tuesday, September 9, 2014 8:26:37 AM UTC-7, Naoki INADA wrote:
>>>
>>> I've fixed them and released mysqlclient 1.3.3.
>>> https://pypi.python.org/pypi/mysqlclient
>>>
>>> On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:

 I've fixed `%(xxx)s` style formatting.

 I have not changed error switch:
 https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
 https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180

 I'll investigate the problem, but I can't promise any date for fixing 
 it.


 On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>
> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>
>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham  
>> wrote: 
>> > We'd need mysqlclient to support Python 3.2 (or drop official 
>> support for 
>> > MySQL/Python 3.2): 
>>
>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>> many Unicode API has 
>> been changed and deprecated.  It also introduce unicode literal. 
>> Supporting Python 3.2 will make code messy. 
>>
>> I want to drop Python 3.2 support since I believe most Python 3 users 
>> are aggressive enough 
>> to go forward. 
>>
>> How Python 3.2 important for you? 
>>
>
> I think we could live with MySQL not supporting Python 3.2. 
>
> > Python 2.7 test failures: 
>> > 
>> > 
>> > custom_pk.tests.CustomPKTests.test_required_pk 
>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>> > 
>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>  
>>
>> > 
>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>
>
> Thanks Tim for testing. These errors seem to all have the same origin, 
> null inserts into not-null columns generate OperationalError instead of 
> IntegrityError.
>  
>
>> > Python 3.4 test failures: 
>> > 
>> > 
>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>> > 
>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>> > 
>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>  
>>
>> > custom_pk.tests.CustomPKTests.test_required_pk 
>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>> > 
>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>  
>>
>> > 
>> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>> > model_fields.tests.BooleanFieldTests.test_null_default 
>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>
>>
> In addition of the above issue, it seems that pyformat isn't supported 
> for Python3. Something around these lines:
> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
> {"val1": value_1, "val2": value_2})
>
> I've created issues on the mysqlclient bug tracker.
> https://github.com/PyMySQL/mysqlclient-python/issues/3
> https://github.com/PyMySQL/mysqlclient-python/issues/4
>
> Claude
>
>  
>


-- 
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

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Daniel Pyrathon

Hi,

I think that changing the name the community on google will create many
broken links, this will be a huge loss.
What we can do instead, is create 2 domains (or subdomains) such as
core-development.djangoproject.com and community.djangoproject.com that
will serve as the official URLs to publicise on blogs, official sites and
IRC. These ULRs will redirect to the related google forums.

Dan

On Tuesday, September 9, 2014, Erik Romijn  wrote:

> I think it would also be a great improvement if we all adopted a standard
> response for these kind of mails - because no matter what we do, some will
> still end up here.
>
> Almost entirely based on Daniele's previous responses, how about we use:
>
> > The best place to get answers to your questions is the django-users
> email list, > - the web
> interface is .
> >
> > The list you've posted to is django-developers, an email list is for the
> discussion of the development of Django itself.
> >
> > You might also find helpful the #django IRC channel on irc.freenode.net.
> >
> > I hope that helps,
>
> This focuses first on helping them get to the right place, with easily
> readable language, and then explains their error in a friendly way. In the
> past, we've occasionally sent somewhat more harsh replies, focusing more on
> how they did something wrong. Although I'm sure such replies were
> absolutely sent with the best intentions, it's not a pleasant first
> experience.
>
> Not sure what the best place is to keep this template easily accessible
> for anyone though. The wiki might be the most suitable.
>
> Erik
>
> --
> 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/07EC2CEB-A0AC-4624-874C-6D8FBD9D594C%40solidlinks.nl
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
*

PirosB3

https://github.com/PirosB3

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

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Aymeric Augustin

Benjamin,

Please read my email again. I did not take a side in the debate.

I didn't say anything about the two PRs or your arguments.

I didn't support your position but I didn't reject it either.

Please realize that your answer expresses prejudice about my beliefs and that 
it paints me as a clueless person for no good reason. It attempts to force me 
to pick a side, and rather aggressively, while I'm not ready to do so in public.

Please consider that I'm unfamiliar with the American cultural standards that 
underlie this entire debate and uncomfortable with participating as a 
non-native speaker, as the topic is too sensitive to allow for approximative 
vocabulary.

That said, may I suggest kindly that you cool down a bit and read what others 
write?

-- 
Aymeric.



On 9 sept. 2014, at 21:28, Benjamin Scherrey  wrote:

> Aymeric,
> 
> You don't believe that one should also consider how it is used? I have 
> already documented that the single ever documented threatened use of the 
> existing code of conduct was not to protect anyone from harassment but, in 
> fact, was used to stifle someone's thoughtful and reasoned argument and end 
> debate on a point. Exactly the kind of thing that I commonly see in the rest 
> of the world where such speech and conduct codes are applied. They inevitably 
> lead to this and I find that coercive and destructive. Evil in the name of 
> good is twice as evil.
> 
> I will also note that I have made several direct assertions about the 
> positive aspects and negative aspects of certain policies. The sudden influx 
> of people speaking in support for a speech and conduct code that enumerates 
> forbidden activities have all chosen not to respond to any of these 
> assertions with reasoned arguments or provide any assertions of their own 
> backed up by evidence. None. Zero. I think that speaks very much towards the 
> quality of their arguments and the resulting policies if their preferences 
> are chosen. Sadly, I also anticipated this when I replied to Kevin's latest 
> post asking for those who supported the speech code to respond to my concerns 
> directly because the usual tactic by people wishing to impose such things is 
> to argue around the subject rather than address the real documented problems 
> with it. Alex gets partial credit for at least giving some specific support 
> (the Ada group's recommendation) for why he wants it but no one has bothered 
> to address the clear and present documented dangers of such a thing as I have 
> argued.
> 
> Again, getting back to the subject of the two PRs, 84 is fine but 86 is 
> way out of line because you've then imposed a speech and conduct code on the 
> entire universe without any context of having anything to do with Django. 
> Nothing good can come of this.
> 
> -- Ben
> 
> On Wed, Sep 10, 2014 at 2:12 AM, Aymeric Augustin 
>  wrote:
> On 9 sept. 2014, at 19:54, Benjamin Scherrey  wrote:
> 
> > So far we have exactly one documented example and TPTB took it seriously 
> > right away. To me, this hardly justifies any need for an explicit 
> > "anti-harassment" policy.
> 
> I believe the success of the code of conduct is measured by how rarely it is 
> needed.
> 
> If it never needs to be brought up, then it has achieved its goal.
> 
> So thanks for confirming that it works well :-)
> 
> --
> Aymeric.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/E4FAFFC8-DEA4-411D-9130-EA9BC74090B0%40polytechnique.org.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Chief Systems Architect Proteus Technologies
> Chief Fan Biggest Fan Productions
> Personal blog where I am not your demographic.
> 
> This email intended solely for those who have received it. If you have 
> received this email by accident - well lucky you!!
> 
> -- 
> 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/CAHN%3D9D79ZSdh_oHBNdu8kSkv6oeS4tS3Ekgw6Ygz_Ft_xqUh%2Bg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread James Bennett

I have been involved in building and participating in and running
technically-oriented groups for fifteen years. I've seen a lot of stuff.

The most common problem pattern I have seen is the "I'm not touching you"
game. To understand what this means, imagine parents driving a car, with
two children in the back seat. Child A keeps poking Child B, so the parents
instruct Child A to stop touching Child B. A few moments later, things
resume, but now Child A says "I didn't touch him, the sleeve of my shirt
touched him, you didn't say the sleeve of my shirt couldn't touch him". And
away we go as Child A comes up with ever more convoluted technicalities to
try to keep harassing Child B while still claiming it "wasn't against the
rules".

The "I'm not touching you" game is also a favorite of many types of people
on the internet. Avoiding it requires policies which contain both
affirmative and negative statements (i.e., lists of things
encouraged/expected, lists of things forbidden) as well as a certain amount
of discretion -- even, dare I say, a vague but probably large amount -- to
be left in the hands of whichever person or persons will be responsible for
enforcement, so that we don't end up playing "I'm not touching you" until
the end of time. That little bit of discretion to step outside the stark
technicalities and just bluntly deal with such people makes, in my
experience at least, all the difference between a workable and an
unworkable policy.

So those are things that need to be in our CoC. If they make you
uncomfortable, if you don't trust the leaders of this community to handle
things fairly and responsibly, if you are chilled, silenced and terrified
byt the idea that harassing behavior would result in ostracism from the
Django community, then perhaps the Django community is simply not the place
for you, because the kind of community we want to have and the kind of
community you want to have may not be compatible.

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

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Corey Farwell

It is a valid concern. That said, I'd rather the documentation recommend a 
GPL, Python 3+2, working MySQL connector over a GPL, Python 2, partially 
broken MySQL connector.

On Tuesday, September 9, 2014 3:21:08 PM UTC-4, Daniel Sears wrote:
>
> Aside from the technical issues, there are the licensing issues. The 
> Django community strongly prefers BSD-style licensing and both mysqldb and 
> MySQL Connector/Python use GPL licenses. For an e-mail thread which 
> addresses these GPL issues, see
>
>
> https://groups.google.com/forum/#!msg/django-developers/8r_RVmUe5ys/09lCwJl-L1kJ
>
> PyMySQL does appear to have a BSD-like license.
>
> --Dan
>
>
> On Tuesday, September 9, 2014 8:26:37 AM UTC-7, Naoki INADA wrote:
>>
>> I've fixed them and released mysqlclient 1.3.3.
>> https://pypi.python.org/pypi/mysqlclient
>>
>> On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>>>
>>> I've fixed `%(xxx)s` style formatting.
>>>
>>> I have not changed error switch:
>>> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
>>> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>>>
>>> I'll investigate the problem, but I can't promise any date for fixing it.
>>>
>>>
>>> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:

 On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>
> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham  
> wrote: 
> > We'd need mysqlclient to support Python 3.2 (or drop official 
> support for 
> > MySQL/Python 3.2): 
>
> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
> many Unicode API has 
> been changed and deprecated.  It also introduce unicode literal. 
> Supporting Python 3.2 will make code messy. 
>
> I want to drop Python 3.2 support since I believe most Python 3 users 
> are aggressive enough 
> to go forward. 
>
> How Python 3.2 important for you? 
>

 I think we could live with MySQL not supporting Python 3.2. 

 > Python 2.7 test failures: 
> > 
> > 
> > custom_pk.tests.CustomPKTests.test_required_pk 
> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
> > 
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>  
>
> > 
> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
> > model_fields.tests.BooleanFieldTests.test_null_default 
>

 Thanks Tim for testing. These errors seem to all have the same origin, 
 null inserts into not-null columns generate OperationalError instead of 
 IntegrityError.
  

> > Python 3.4 test failures: 
> > 
> > 
> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
> > 
> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>  
>
> > custom_pk.tests.CustomPKTests.test_required_pk 
> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
> > 
> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>  
>
> > 
> get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
> > model_fields.tests.BooleanFieldTests.test_null_default 
> > raw_query.tests.RawQueryTests.test_pyformat_params 
>
>
 In addition of the above issue, it seems that pyformat isn't supported 
 for Python3. Something around these lines:
 cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
 {"val1": value_1, "val2": value_2})

 I've created issues on the mysqlclient bug tracker.
 https://github.com/PyMySQL/mysqlclient-python/issues/3
 https://github.com/PyMySQL/mysqlclient-python/issues/4

 Claude

  

>>>

-- 
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/a6bb5190-eebf-466c-b0d7-0c592ce7c6bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

Aymeric,

You don't believe that one should also consider how it is used? I have
already documented that the single ever documented threatened use of the
existing code of conduct was not to protect anyone from harassment but, in
fact, was used to stifle someone's thoughtful and reasoned argument and end
debate on a point. Exactly the kind of thing that I commonly see in the
rest of the world where such speech and conduct codes are applied. They
inevitably lead to this and I find that coercive and destructive. Evil in
the name of good is twice as evil.

I will also note that I have made several direct assertions about the
positive aspects and negative aspects of certain policies. The sudden
influx of people speaking in support for a speech and conduct code that
enumerates forbidden activities have all chosen not to respond to any of
these assertions with reasoned arguments or provide any assertions of their
own backed up by evidence. None. Zero. I think that speaks very much
towards the quality of their arguments and the resulting policies if their
preferences are chosen. Sadly, I also anticipated this when I replied to
Kevin's latest post asking for those who supported the speech code to
respond to my concerns directly because the usual tactic by people wishing
to impose such things is to argue around the subject rather than address
the real documented problems with it. Alex gets partial credit for at least
giving some specific support (the Ada group's recommendation) for why he
wants it but no one has bothered to address the clear and present
documented dangers of such a thing as I have argued.

Again, getting back to the subject of the two PRs, 84 is fine but 86 is
way out of line because you've then imposed a speech and conduct code on
the entire universe without any context of having anything to do with
Django. Nothing good can come of this.

-- Ben

On Wed, Sep 10, 2014 at 2:12 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 9 sept. 2014, at 19:54, Benjamin Scherrey  wrote:
>
> > So far we have exactly one documented example and TPTB took it seriously
> right away. To me, this hardly justifies any need for an explicit
> "anti-harassment" policy.
>
> I believe the success of the code of conduct is measured by how rarely it
> is needed.
>
> If it never needs to be brought up, then it has achieved its goal.
>
> So thanks for confirming that it works well :-)
>
> --
> Aymeric.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/E4FAFFC8-DEA4-411D-9130-EA9BC74090B0%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Chief Systems Architect Proteus Technologies 
Chief Fan Biggest Fan Productions 
Personal blog where I am not your demographic
.

This email intended solely for those who have received it. If you have
received this email by accident - well lucky you!!

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

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Daniel Sears

Aside from the technical issues, there are the licensing issues. The Django 
community strongly prefers BSD-style licensing and both mysqldb and MySQL 
Connector/Python use GPL licenses. For an e-mail thread which addresses 
these GPL issues, see

https://groups.google.com/forum/#!msg/django-developers/8r_RVmUe5ys/09lCwJl-L1kJ

PyMySQL does appear to have a BSD-like license.

--Dan


On Tuesday, September 9, 2014 8:26:37 AM UTC-7, Naoki INADA wrote:
>
> I've fixed them and released mysqlclient 1.3.3.
> https://pypi.python.org/pypi/mysqlclient
>
> On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>>
>> I've fixed `%(xxx)s` style formatting.
>>
>> I have not changed error switch:
>> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
>> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>>
>> I'll investigate the problem, but I can't promise any date for fixing it.
>>
>>
>> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>>
>>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:

 On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham  
 wrote: 
 > We'd need mysqlclient to support Python 3.2 (or drop official support 
 for 
 > MySQL/Python 3.2): 

 Python 3.3 introduces PEP 393 (Flexible String Representation) and 
 many Unicode API has 
 been changed and deprecated.  It also introduce unicode literal. 
 Supporting Python 3.2 will make code messy. 

 I want to drop Python 3.2 support since I believe most Python 3 users 
 are aggressive enough 
 to go forward. 

 How Python 3.2 important for you? 

>>>
>>> I think we could live with MySQL not supporting Python 3.2. 
>>>
>>> > Python 2.7 test failures: 
 > 
 > 
 > custom_pk.tests.CustomPKTests.test_required_pk 
 > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
 > 
 generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
  

 > 
 get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
 > get_or_create.tests.UpdateOrCreateTests.test_integrity 
 > model_fields.tests.BooleanFieldTests.test_null_default 

>>>
>>> Thanks Tim for testing. These errors seem to all have the same origin, 
>>> null inserts into not-null columns generate OperationalError instead of 
>>> IntegrityError.
>>>  
>>>
 > Python 3.4 test failures: 
 > 
 > 
 > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
 > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
 > 
 backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
  

 > custom_pk.tests.CustomPKTests.test_required_pk 
 > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
 > 
 generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
  

 > 
 get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
 > get_or_create.tests.UpdateOrCreateTests.test_integrity 
 > model_fields.tests.BooleanFieldTests.test_null_default 
 > raw_query.tests.RawQueryTests.test_pyformat_params 


>>> In addition of the above issue, it seems that pyformat isn't supported 
>>> for Python3. Something around these lines:
>>> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
>>> {"val1": value_1, "val2": value_2})
>>>
>>> I've created issues on the mysqlclient bug tracker.
>>> https://github.com/PyMySQL/mysqlclient-python/issues/3
>>> https://github.com/PyMySQL/mysqlclient-python/issues/4
>>>
>>> Claude
>>>
>>>  
>>>
>>

-- 
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/ed5e0901-c632-4c47-9aa4-72ea54f0a97c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Aymeric Augustin

On 9 sept. 2014, at 19:54, Benjamin Scherrey  wrote:

> So far we have exactly one documented example and TPTB took it seriously 
> right away. To me, this hardly justifies any need for an explicit 
> "anti-harassment" policy. 

I believe the success of the code of conduct is measured by how rarely it is 
needed.

If it never needs to be brought up, then it has achieved its goal.

So thanks for confirming that it works well :-)

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E4FAFFC8-DEA4-411D-9130-EA9BC74090B0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread kate heddleston

I also agree with listing the things people shouldn't do at conferences. 
Listing lines that they should stay within is good. Listing lines they 
shouldn't cross is also good. A code of conduct can happily have both.

On Saturday, September 6, 2014 9:10:42 PM UTC-4, Kevin Daum wrote:
>
> I have submitted two pull requests for the code of conduct:
>
>- #84 , to let 
>folks who belong to a wide variety of social identities know that yes, 
> even 
>they are welcome here, and
>- #86 , to make 
>explicit the currently implicit policy that someone's abusive behavior 
>outside the django community *may* have an adverse effect on their 
>ability to participate within the django community.
>
> I welcome your feedback. 
>
> Thanks,
> Kevin Daum
>
>

-- 
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/e1eb3e8a-65c0-4380-b907-5d31e210cd17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread 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.

On Tue, Sep 9, 2014, 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.

It's important to list things like this. The fact that it's impossible to list 
every possible one is not a good reason not to list some.

No-one thinks that their behaviour is objectionable, otherwise they wouldn't be 
doing it. Explicitly mentioning particular examples of behaviour helps make it 
harder for someone to "not realise" that what they are doing is unwelcome.

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

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Jeremy Dunck

As someone affected by an issue that would fall under the proposed change
[1], I still support an explicit guideline about external behavior
influencing internal acceptance.  The safety of all members is more
important than the risk of misapplication of the rule.

[1]
http://doubleunion.tumblr.com/post/77929475144/how-not-to-support-women-in-tech
On Sep 9, 2014 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 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/CAM0i3f5yRYBy6qGO1R2x9QOANi_xRDCTVLBuZ7qZL2%3DwMjduPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread Alex Gaynor

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.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread barbara.shaurette

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.

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread kate heddleston

I wholeheartedly support the measure to change the language and more 
explicitly state that behavior in discordance with the Django code of 
conduct outside the walls of Django events can affect participation within 
the walls of Django events. The community itself spans both spaces, and you 
cannot effectively create a safe space for community members during the 
week of DjangoCon while ignoring behavior at all other times. 

As for the code of conduct containing affirmative rules that lay out 
behavior that attendees should follow, I am also in support of that. I look 
forward to the PR that contains the rules and guidelines detailing 
recommended conference behavior.

Many of the counterarguments do not address the change at hand but the code 
of conduct as a whole and call for an objective application of these rules 
to community members. Objectivity for a set of rules regarding humans is a 
tall order. Even the law recognizes its lack of objectivity and has in 
place checks and balances; the Constitution is a great document in part 
because it lays forth a set of somewhat ambiguous guidelines that are open 
to interpretation in their application. Objectivity is not the goal with 
the code of conduct; the goal is to create rules that help others 
understand how to make our community a safe space for all people. If you 
are concerned with how the code of conduct is enforced, you should open a 
thread to discuss the checks and balances the Django community puts in 
place when reviewing code of conduct violations.

On Saturday, September 6, 2014 9:10:42 PM UTC-4, Kevin Daum wrote:
>
> I have submitted two pull requests for the code of conduct:
>
>- #84 , to let 
>folks who belong to a wide variety of social identities know that yes, 
> even 
>they are welcome here, and
>- #86 , to make 
>explicit the currently implicit policy that someone's abusive behavior 
>outside the django community *may* have an adverse effect on their 
>ability to participate within the django community.
>
> I welcome your feedback. 
>
> Thanks,
> Kevin Daum
>
>

-- 
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/6f3184fc-1d36-4b47-8e67-9b30998edab7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

Kevin,

Again I believe your heart is in the right place but the presumption in
your message is that there are people who need and deserve special
protection above and beyond other members of the community. While, well
intentioned, we all know how the road to hell got paved. A good policy is
one that affords benefits to all members equally or it shouldn't be in
place at all. That's why I propose an affirmative policy which is inclusive
rather than a speech or conduct code which never works as their stated
purpose would claim.

That said, I welcome any thoughtful critiques or feedback on any of the
assertions and recommendations I have made. I would especially like to know
what aspect of an affirmative policy someone who supports the other kind
finds deficient and have real evidence supporting their position if that is
the case.

best regards,

  -- Ben Scherrey

On Tue, Sep 9, 2014 at 11:33 PM, 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.
>

-- 
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/CAHN%3D9D7rZt8o6Ypoh8Z0ErXR3YYQ89_6SaW-q4WSgb8ewzdj%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

Hi Stephen,

Out of your three links only the 3rd describes an actual harassment
occurring at a Django-related event. It also describes that as soon as the
person reported it to the conference director she got an immediate positive
response by the director who seems to have made every attempt to be helpful
despite the lack of a written policy being in place at the time. Your first
link is written by someone who described how exceptional DjangoCon is in
that she was never harassed.

So far we have exactly one documented example and TPTB took it
seriously right away. To me, this hardly justifies any need for an explicit
"anti-harassment" policy. In fact, all "zero-tolerance" policies are, by
definition, "zero-thought" policies and quite dangerous. There is no
evidence that they help and tons of evidence that they do harm and are
abused - which I have already documented in the first and only (so far as I
can tell) threat of invocation of the existing policy.

By your statement "stop talking about it and show us what that would
look like" It seems clear, unfortunately, that you haven't bothered to read
my posts, including my very first response to the PRs in question, because
I have already done just that. I'm very emphatically for an affirmative
policy of inclusiveness and positive conduct which the first PR supported.
I am even more emphatically against a speech and conduct code that lists
banned speech and behavior which the second PR makes even worse.

With an affirmative policy you don't need to ban certain conduct. If
someone acts outside of this policy they are quickly reminded about what
kind of community group this is and offered suggestions in which they might
re-work their approach in order to fit in and be more effective in their
participation. If they do something that is outside of the law, witnesses
can swear out a warrant against them as we are not the police, despite the
appearance that some people seem to want to behave as such. I have found
this kind of policy to be very effective in maintaining a high
signal-to-noise ratio and makes it very clear that there is no fertile
ground here in which to seed hostile acts of any kind.

-- Ben

On Wed, Sep 10, 2014 at 12:26 AM, Stephen Burrows <
stephen.r.burr...@gmail.com> wrote:

> 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

Re: Two proposals for the Django Code of Conduct.

2014-09-09 Thread 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.

2014-09-09 Thread Kevin Daum

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 simply am strong at 
>> identifying and attracting people with strong potential and the market is 
>> so extremely competitive that one must leave no stone unturned in order to 
>> find the best. THAT is the one way that a more inclusive group will come 
>> into being and for the right reasons.
>>
>> So I have actually achieved what everyone is crying out for and can't 
>> seem to figure how to accomplish. It wasn't difficult. I'm here to tell you 
>> that diversity policies and codes of conduct, in my experience consulting 
>> to dozens of commercial, government, and educational organizations in my 
>> 30+ years of experience have never once helped achieve their stated goals 
>> and, many times, have hurt both the organization and it's intended 
>> beneficiaries. True to my experience, the one threatened invocation of the 
>> code of conduct for Django fits right in line with my experience of such 
>> policies, sadly. 
>>
>> Therefore, I hope everyone appreciates that I'm fully invested in 
>> Django and attracting the best & brightest into our community. I think 
>> you'll see Kevin, that I supported your first PR but have very grave 
>> concerns about the second for the reasons I've already gone into great 
>> detail about. I do believe completely that both

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Erik Romijn

I think it would also be a great improvement if we all adopted a standard 
response for these kind of mails - because no matter what we do, some will 
still end up here.

Almost entirely based on Daniele's previous responses, how about we use:

> The best place to get answers to your questions is the django-users email 
> list,  - the web interface is 
> . 
> 
> The list you've posted to is django-developers, an email list is for the 
> discussion of the development of Django itself.
> 
> You might also find helpful the #django IRC channel on irc.freenode.net.
> 
> I hope that helps,

This focuses first on helping them get to the right place, with easily readable 
language, and then explains their error in a friendly way. In the past, we've 
occasionally sent somewhat more harsh replies, focusing more on how they did 
something wrong. Although I'm sure such replies were absolutely sent with the 
best intentions, it's not a pleasant first experience.

Not sure what the best place is to keep this template easily accessible for 
anyone though. The wiki might be the most suitable.

Erik

-- 
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/07EC2CEB-A0AC-4624-874C-6D8FBD9D594C%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

On Tue, Sep 9, 2014, Thomas Leo  wrote:

>> and in most cases one has the impression that successfully finding a 
>place to
>> ask a question and writing a message expressing their question about 
>Django
>> development is an achievement in itself for them.
>
>This seems rather condescending to new Django users.

I wasn't referring to new Django users, but people for whom it is a significant 
extra effort to read and write in English.

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

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Thomas Leo

+1 for @Wim Feijen's rewording but...

I think the wording of the Group description isn't the issue, my guess is
that people who make the mistake of asking django-user's questions in the
django-developers mailing list didn't read the description to begin with.

> They are almost all from people whose first language is clearly not 
English,

I haven't been following this mailing list for a particularly long time, 
but I
can recall a number of cases where users were simply noobies looking for 
help,
and didn't reading the description of this mailing list before asking their
question.  Whether they are native English speakers or not, clearer wording
would mitigate the issue for everyone.

> and in most cases one has the impression that successfully finding a 
place to
> ask a question and writing a message expressing their question about 
Django
> development is an achievement in itself for them.

This seems rather condescending to new Django users.

On Tuesday, September 9, 2014 5:19:25 AM UTC-4, Daniele Procida wrote:
>
> On Tue, Sep 9, 2014, Robert Grant  
> wrote: 
>
> >Totally agree Daniele. I don't know how other people experience the 
> group, 
> >but I actually didn't see the email address, and didn't even look at the 
> >URL. 
>
> I'm not sure how much effect any of this will have. 
>
> We get a few (I'd say about three or four) messages a week to 
> django-developers that should have gone to django-users. 
>
> They are almost all from people whose first language is clearly not 
> English, and in most cases one has the impression that successfully finding 
> a place to ask a question and writing a message expressing their question 
> about Django development is an achievement in itself for them. 
>
> As long as this email list is the first one that appears in a web serch 
> for things like "django developer email list", it's going to be where their 
> messages get sent. 
>
> It may actually have more effect to change the name and description of 
> django-users, to "For developers working with Django" and "Discussion group 
> for developers working with the Django web framework: djangoproject.com. 
> New members and beginners are welcome". 
>
> 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/1d6f3d48-6c5a-49db-b168-28d7c0ae3415%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Naoki INADA

I've fixed them and released mysqlclient 1.3.3.
https://pypi.python.org/pypi/mysqlclient

On Tuesday, September 9, 2014 3:29:45 PM UTC+9, Naoki INADA wrote:
>
> I've fixed `%(xxx)s` style formatting.
>
> I have not changed error switch:
> https://github.com/PyMySQL/mysqlclient-python/blob/master/_mysql.c#L150
> https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L180
>
> I'll investigate the problem, but I can't promise any date for fixing it.
>
>
> On Tuesday, September 9, 2014 12:35:26 AM UTC+9, Claude Paroz wrote:
>>
>> On Monday, September 8, 2014 5:19:56 PM UTC+2, Naoki INADA wrote:
>>>
>>> On Mon, Sep 8, 2014 at 11:28 PM, Tim Graham  wrote: 
>>> > We'd need mysqlclient to support Python 3.2 (or drop official support 
>>> for 
>>> > MySQL/Python 3.2): 
>>>
>>> Python 3.3 introduces PEP 393 (Flexible String Representation) and 
>>> many Unicode API has 
>>> been changed and deprecated.  It also introduce unicode literal. 
>>> Supporting Python 3.2 will make code messy. 
>>>
>>> I want to drop Python 3.2 support since I believe most Python 3 users 
>>> are aggressive enough 
>>> to go forward. 
>>>
>>> How Python 3.2 important for you? 
>>>
>>
>> I think we could live with MySQL not supporting Python 3.2. 
>>
>> > Python 2.7 test failures: 
>>> > 
>>> > 
>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>> > 
>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>  
>>>
>>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>>
>>
>> Thanks Tim for testing. These errors seem to all have the same origin, 
>> null inserts into not-null columns generate OperationalError instead of 
>> IntegrityError.
>>  
>>
>>> > Python 3.4 test failures: 
>>> > 
>>> > 
>>> > backends.tests.BackendTestCase.test_cursor_execute_with_pyformat 
>>> > backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat 
>>> > 
>>> backends.tests.BackendTestCase.test_cursor_executemany_with_pyformat_iterator
>>>  
>>>
>>> > custom_pk.tests.CustomPKTests.test_required_pk 
>>> > fixtures.tests.FixtureLoadingTests.test_loaddata_error_message 
>>> > 
>>> generic_relations_regress.tests.GenericRelationTests.test_target_model_is_unsaved
>>>  
>>>
>>> > get_or_create.tests.GetOrCreateTests.test_get_or_create_invalid_params 
>>> > get_or_create.tests.UpdateOrCreateTests.test_integrity 
>>> > model_fields.tests.BooleanFieldTests.test_null_default 
>>> > raw_query.tests.RawQueryTests.test_pyformat_params 
>>>
>>>
>> In addition of the above issue, it seems that pyformat isn't supported 
>> for Python3. Something around these lines:
>> cursor.execute("INSERT INTO table f1, f2 values(%(val1)s, %(val2)s)", 
>> {"val1": value_1, "val2": value_2})
>>
>> I've created issues on the mysqlclient bug tracker.
>> https://github.com/PyMySQL/mysqlclient-python/issues/3
>> https://github.com/PyMySQL/mysqlclient-python/issues/4
>>
>> Claude
>>
>>  
>>
>

-- 
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/35badf29-051c-44af-9938-607ed2a7d1ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Draft DEP: ORM expressions API changes

2014-09-09 Thread Anssi Kääriäinen

I have written a DEP about planned ORM expressions API changes. See
https://github.com/django/deps/pull/5 for the proposed DEP.

The plan is to throw away sql.expressions.SQLEvaluator, rewrite how
expressions work and make aggregates subclasses of expressions.

Short summary of the goals and problems of the DEP:
  - The aim is to allow writing custom expressions through public API,
allow usage of F() expressions in annotations and doing arithmetic
operations on aggregates
  - Simplify coding of the ORM
  - The DEP is based on work done by Josh Smeaton in pull request
https://github.com/django/django/pull/2496. While the patch will solve
multiple issues, the main ticket tracking these changes is #14030.
  - The main problem is backwards compatibility - writing custom
expressions or non-SQL backends requires usage of private APIs. The DEP
aims to change those private APIs.

I am planning to actually include the DEP as a draft in the django/deps
repository once the most problematic pats of the draft have been
rewritten. Once committed into the django/deps repository collaboration
on the DEP will be much easier.

As there isn't currently any process for actually accepting DEPs it
might be possible that we need to move on with Josh Smeaton's work
before the DEP is formally accepted. Of course, I hope that we get the
DEP process going on, so we can first accept the DEP, then commit the
actual implementation.

Comments on the ORM epressions API changes should go to the pull request
for now. Comments on the DEP process itself are welcome here.

 - Anssi

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

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Florian Apolloner

Python 2.7.3 and MySQL_python-1.2.5-cp27-none-linux_x86_64.whl

On Tuesday, September 9, 2014 10:41:40 AM UTC+2, Naoki INADA wrote:
>
> I run django tests using MySQL-python 1.2.5 (aka, MySQLdb1) and Python 
> 2.7.8. 
> So it means django doesn't work with MySQL with MySQL-python. 
>
> $ python -V 
> Python 2.7.8 
> (mysql2)[inada-n@MBA:~] 
> $ pip list 
> MySQL-python (1.2.5) 
> pip (1.5.6) 
> setuptools (3.6) 
> wsgiref (0.1.2) 
>
> On Tue, Sep 9, 2014 at 5:18 PM, Florian Apolloner  > wrote: 
> > On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote: 
> >> 
> >> Failed to install index for admin_views.PrePopulatedPostLargeSlug 
> >> model: (1071, 'Specified key was too long; max key length is 767 
> bytes') 
> > 
> > 
> > Welcome to the wonderful world to mysql, afaik this is a warning and not 
> an 
> > error; so your database driver might convert that incorrectly. 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "Django developers" group. 
> > To unsubscribe from this topic, visit 
> > 
> https://groups.google.com/d/topic/django-developers/n-TI8mBcegE/unsubscribe. 
>
> > To unsubscribe from this group and all its topics, send an email to 
> > django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/4bd04867-0f32-4db2-85b3-41671f92aecc%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> INADA Naoki   
>

-- 
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/e4a2365f-625b-4154-8e5f-dda3a206ec33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Florian Apolloner

http://djangoci.com/ disagrees with you :) Would have to check the specific 
mysqldb version. 

-- 
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/01a5f888-75c2-4315-9ad0-e52359b215de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

On Tue, Sep 9, 2014, Robert Grant wrote:

>Totally agree Daniele. I don't know how other people experience the group,
>but I actually didn't see the email address, and didn't even look at the
>URL.

I'm not sure how much effect any of this will have.

We get a few (I'd say about three or four) messages a week to django-developers
that should have gone to django-users.

They are almost all from people whose first language is clearly not English,
and in most cases one has the impression that successfully finding a place to
ask a question and writing a message expressing their question about Django
development is an achievement in itself for them.

As long as this email list is the first one that appears in a web serch for
things like "django developer email list", it's going to be where their
messages get sent.

It may actually have more effect to change the name and description of
django-users, to "For developers working with Django" and "Discussion group for
developers working with the Django web framework: djangoproject.com. New
members and beginners are welcome".

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

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Wim Feijen

Hi,

Good thing to change the group name. For the description, another wording 
could be:

Discussion group for contributing to the Django source code and 
documentation. Here we discuss new features and updates of the Django 
project. 

Wim


On Tuesday, 9 September 2014 10:52:09 UTC+2, Robert Grant wrote:
>
> Totally agree Daniele. I don't know how other people experience the group, 
> but I actually didn't see the email address, and didn't even look at the 
> URL. If we can find where the email is exposed (say on a website) and 
> change things to hide it as much as possible, e.g.: 
>
> Instead of : Email the Django Contributors group here: 
> django-d...@googlegroups.com 
> Say : Email the Django Contributors group .
>
> That might help. Maybe a note in the description to say that for 
> historical reasons, if you want to email a new topic to the group the email 
> address is django-d...@googlegroups.com ?
>
> On Tuesday, 9 September 2014 10:03:45 UTC+2, Daniele Procida wrote:
>>
>> On Tue, Sep 9, 2014, Russell Keith-Magee  wrote: 
>>
>> >As a matter of formality, I'd like to put this through the technical 
>> board 
>> >so that it isn't just a fiat decision by the handful of people motivated 
>> to 
>> >participate in this discussion. 
>>
>> By the way, there are three related pieces of information (in Manage > 
>> Information > General information): 
>>
>> Group name: Django developers 
>>
>> Group email address: django-developers (can't be changed) 
>>
>> Group description: Discussion group for Django developers. This group is 
>> used for discussion of developing Django itself, not user questions; Please 
>> use django-users for issues regarding using the framework, questions for 
>> the Django user community outreach, etc. 
>>
>>
>> The description's the easy one, but I don't think it's going to make a 
>> huge amount of difference. I doubt it's what catches people's attention. 
>> I'd suggest something shorter like: 
>>
>> Discussion group for the development of Django and contribution to 
>> the 
>> project. For questions about and help with Django, please use 
>> django-users. 
>>
>> The group name is the problematic one. If it matches the email address; 
>> it's misleading; if it doesn't, it's confusing. 
>>
>> 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/bf7ba047-d45f-49f1-9a16-ac4b54423894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group

2014-09-09 Thread Robert Grant

Totally agree Daniele. I don't know how other people experience the group, 
but I actually didn't see the email address, and didn't even look at the 
URL. If we can find where the email is exposed (say on a website) and 
change things to hide it as much as possible, e.g.: 

Instead of : Email the Django Contributors group here: 
django-developers@googlegroups.com
Say : Email the Django Contributors group 
.

That might help. Maybe a note in the description to say that for historical 
reasons, if you want to email a new topic to the group the email address is 
django-developers@googlegroups.com?

On Tuesday, 9 September 2014 10:03:45 UTC+2, Daniele Procida wrote:
>
> On Tue, Sep 9, 2014, Russell Keith-Magee  > wrote: 
>
> >As a matter of formality, I'd like to put this through the technical 
> board 
> >so that it isn't just a fiat decision by the handful of people motivated 
> to 
> >participate in this discussion. 
>
> By the way, there are three related pieces of information (in Manage > 
> Information > General information): 
>
> Group name: Django developers 
>
> Group email address: django-developers (can't be changed) 
>
> Group description: Discussion group for Django developers. This group is 
> used for discussion of developing Django itself, not user questions; Please 
> use django-users for issues regarding using the framework, questions for 
> the Django user community outreach, etc. 
>
>
> The description's the easy one, but I don't think it's going to make a 
> huge amount of difference. I doubt it's what catches people's attention. 
> I'd suggest something shorter like: 
>
> Discussion group for the development of Django and contribution to the 
> project. For questions about and help with Django, please use 
> django-users. 
>
> The group name is the problematic one. If it matches the email address; 
> it's misleading; if it doesn't, it's confusing. 
>
> 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/3ea22c0c-65b2-446b-bb25-acae01185c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread INADA Naoki

I run django tests using MySQL-python 1.2.5 (aka, MySQLdb1) and Python 2.7.8.
So it means django doesn't work with MySQL with MySQL-python.

$ python -V
Python 2.7.8
(mysql2)[inada-n@MBA:~]
$ pip list
MySQL-python (1.2.5)
pip (1.5.6)
setuptools (3.6)
wsgiref (0.1.2)

On Tue, Sep 9, 2014 at 5:18 PM, Florian Apolloner  wrote:
> On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote:
>>
>> Failed to install index for admin_views.PrePopulatedPostLargeSlug
>> model: (1071, 'Specified key was too long; max key length is 767 bytes')
>
>
> Welcome to the wonderful world to mysql, afaik this is a warning and not an
> error; so your database driver might convert that incorrectly.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/n-TI8mBcegE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/4bd04867-0f32-4db2-85b3-41671f92aecc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
INADA Naoki  

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

Re: [RFC] Python 3 and MySQL

2014-09-09 Thread Florian Apolloner

On Tuesday, September 9, 2014 9:22:10 AM UTC+2, Naoki INADA wrote:
>
> Failed to install index for admin_views.PrePopulatedPostLargeSlug 
> model: (1071, 'Specified key was too long; max key length is 767 bytes')
>

Welcome to the wonderful world to mysql, afaik this is a warning and not an 
error; so your database driver might convert that incorrectly. 

-- 
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/4bd04867-0f32-4db2-85b3-41671f92aecc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The greatest proposal yet: rename this damn group