Re: Websockets... again

[Justin Holmes]

Luis,

I think what Alex and Aymeric are saying is that "websockets" (I use
quotes to show that I mean not only the material outlined in RFC 6455
but also the general process of handling bytes-on-the-wire when
'pushing' data to the 'client') are ideally not part of the problem
that Django (and WSGI applications generally) are trying to solve.
Correct me if I'm wrong, gentlemen.

Alex and Aymeric gave really stellar talks on this topic, at PyCon.us
2010 and Djangocon.us 2013 respectively, and they're really worth
going back and watching.  Of course Aymeric also maintains a websocket
library (https://github.com/aaugustin/websockets).

At the end of the day, handling bytes-on-the-wire is really fun when
done on a different layer than your web MVC application.  Colin
mentioned Hendrix - a Twisted container for Django.  Instead of trying
to "do async" inside of WSIG, Hendrix (and some other WSGI containers)
allow you to run other python applications alongside your WSGI
application.

For example, I have a project called Cirque that uses Hendrix to both
serve a WSGI application (Django) and listen for mesh network traffic
on a UDP port.  It reports mesh traffic to the Django application and
communicates directly with the websockets opened on the
Django-delivered resources.

This way, Django doesn't even need to realize that anything "async" is
happening.

It is also definitely worth paying attention to the web-sig mailing
list.  As you can see, October has been mostly talk of what we want in
the next WSGI 
(https://mail.python.org/pipermail/web-sig/2014-October/thread.html).

This post is starting to grow beyond the django-dev topic.  If you
want to know more about the how's and why's, feel free to post in
django-users.  As far as django development, there seems to be no
compelling argument, at least so far, to change Django's disposition
to make it "async."

On Wed, Oct 29, 2014 at 9:38 AM, Alex Gaynor  wrote:
> And after you throw away the ORM, you have to throw away every other library
> that does blocking IO (anything in the stdlib, memcached, redis, requests,
> etc.). There are absolutely no affordances in WSGI for use with non-blocking
> libraries like asyncio or Twisted.
>
> Alex
>
>
> On Wed Oct 29 2014 at 1:45:59 AM Aymeric Augustin
>  wrote:
>>
>> Then the first step is to throw away the ORM.
>>
>> See my talk at DjangoCon US 2013 for details.
>>
>> --
>> Aymeric.
>>
>> Le 28 oct. 2014 à 23:36, Marco Paolini  a écrit :
>>
>> What if we do it with asyncio?
>>
>> 2014-10-28 22:47 GMT+01:00 Aymeric Augustin
>> :
>>>
>>> No, there isn’t.
>>>
>>> I assume that “including in core” means at least “making usable in
>>> combination with WSGI and with the ORM”.
>>>
>>> Even if we disregard for a minute the fact that WSGI is incompatible with
>>> websockets, the ORM is a hard problem, because current solutions involve
>>> either (a) threads — not particularly scalable or (b) gevent — not
>>> particularly reliable.
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>> On 28 oct. 2014, at 22:06, Luis Masuelli  wrote:
>>>
>>> Is there any current development involving including websockets in django
>>> core?
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/50768d16-1d05-489c-8cbf-2091d95ff388%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/7D3898D4-50F7-4ACE-A081-0ACC9D824191%40polytechnique.org.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> 

Re: Django and BREACH (remember that?)

[Justin Holmes]

Thanks for much for this contribution.  I don't feel particularly qualified
to review it, but there's are particular bits where general django
knowledge (or even just a second pair of eyes) will help, let the know.
On Aug 3, 2014 9:48 PM, "Adam Brenecki"  wrote:

> Hi all,
>
> So, a while ago, BREACH happened, and Django's CSRF implementation was
> vulnerable, as was Rails'. The paper that discussed it described a
> mitigation (and a Rails patch had already been made), so I implemented that
> same mitigation in a Django patch. Discussion on the Trac ticket has
> stalled, and I've been told this is the place to go.
>
> Disclaimer: although I understand enough about it to write the patch, *I'm
> not a security person* - the reason I'm posting here is that I'm hoping
> to get an answer from someone that *is* a security person as to whether
> I'm on the right track.
>
> To jog your memories (and also in the hope that if I'm misunderstanding
> the problem, someone will correct me), the short version of BREACH is: an
> attacker forcing a user to visit a HTTPS page that a) is gzipped, and b)
> contains *in the response body* a secret (in our case, the CSRF token in
> the form), as well as user input (e.g. reflected URL parameters), then
> observing the size of the HTTPS responses. When the user input partially or
> completely matches the secret, the compressed length is slightly shorter,
> and the attacker can use this to guess the secret byte-by-byte.
>
> In section 3 of the paper, the authors describe a variety of mitigations.
> One of them is to, on each request where a secret S should appear,
> generate a new one-time pad P and instead write P + xor(P, S) in the
> response. (The paper also describes other mitigations, but this is the most
> feasible¹.)
>
> My understanding is (and I'll reiterate here I'm not a security person)
> that this should make S impossible to deduce via BREACH, as it doesn't
> appear directly anywhere in the response. As P takes on a new value with
> every request, it simply can't be deduced by any method that involves
> making many requests; therefore the same thing will happen to xor(P, S).
> (I think the fact that P changes every request might have been a point of
> confusion in the Trac discussion; there's a lot of comments there talking
> about trying to deduce P).
>
> The patch I've written implements this mitigation, with one difference:
> instead of using xor, it uses a Vigenère cipher (as suggested by FunkyBob),
> as xor was creating non-printable characters which caused problems. I think
> this should be OK as Vigenère is commonly used for one-time pads and does
> more or less the same thing to characters that xor does to bits.
>
> This is pretty much what django-debreach does, except that *it* uses AES
> instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> processing load to every request and a dependency on PyCrypto, and as far
> as I can tell this doesn't actually add any benefit over xor/Vigenère.
>
> So, in summary, I think I'm doing nearly exactly what the paper says, and
> I think it effectively makes the attack practically impossible, but I'd
> love to hear from someone who has a better idea than I as to if I'm
> actually correct on all of this.
>
> Thanks,
> Adam
>
> The Trac ticket: https://code.djangoproject.com/ticket/20869
> My pull request: https://github.com/django/django/pull/1477
> The original paper:
> http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
> (the relevant bit is section 3.4 at the bottom of page 10)
> The related Rails pull request: https://github.com/rails/rails/pull/11729
>
> ¹ Section 3.4 describes the mitigation I implemented. Section 3.1
> describes fuzzing the lengths of each response by appending random lengths
> of garbage data, then immediately dismisses this method as ineffective;
> Russell Keith-Magee tells me that a discussion within Django reached the
> same conclusion about this one. Apart from those two, they're all things
> like rate limiting and separating secrets from user input, which don't seem
> to me like things we can enforce on a Django level.
>
> --
> 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/66fb5b2b-5f18-4244-92fb-2427b5b63aa8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 

login() documentation assumes no custom auth.User model

[Justin Holmes]

See the example provided for login(), here:

https://docs.djangoproject.com/en/dev/topics/auth/default/#django.contrib.auth.login

It seems to assume that the USERNAME_FIELD is 'username' - ie, that no
custom User model is in place.

I propose adding language here to make it clear that 'username' is
actually USERNAME_FIELD.  Without objection, I'm happy to make the
Pull Request.

Thoughts?

-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
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/CAMGywB5F7dELNDvVkyHrM4U4nW%3DZh%3DyvgD8B%3DAow7NZQB1Ka-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for function application in ORDER BY

[Justin Holmes]

I don't have strong opinions on either of the contentious issues in this
discussion, but I do want to weigh-in and say that I think this is an
important and exciting feature.


On Mon, Jun 9, 2014 at 7:48 PM, Josh Smeaton <josh.smea...@gmail.com> wrote:

> > However, I think having some special case code in filter(), annotate()
> and anything else that takes expressions would be OK
>
> I strongly disagree with this. Expressions are context insensitive at the
> moment, which means they can be used anywhere. If we start externalising
> behaviour based on the context of use, it'll lead us to some very confusing
> code and a tonne of special cases. It would be slightly better if you could
> check the context from the `prepare()` method (are we preparing order_by or
> not), but then I think we'll run into issues where the prepare breaks for
> 3rd party backends - by checking private data. I really do think we'd be
> better off documenting that __neg__ is reserved by Expressions for
> Ordering, and leave it at that.
>
> I'm surprised how easily expressions slotted in to the order_by - I
> thought it'd take a lot more work. Good stuff I think. Some questions:
>
> - should expressions in order_by support random ordering (?) ? I don't
> think so, but I haven't ever had a need for random ordering so I'm not sure.
> - could we reduce the complexity of the order_by machinery by forcing all
> arguments (internally) to be expressions? `order_by('field_a') ->
> order_by(F('field_a'))` etc
>
> These are open questions, not necessarily directed at Tim.
>
> > I haven't yet implemented the LowerCase and related functions
>
> I think we can build out a handy little library of utility functions like
> Lower and Coalesce that could(should) be included directly in django. But
> it'll also open up, to library developers, the ability to easily develop
> backend specific structures, similar to parts of the
> django.contrib.postgres kickstarter.
>
> Cheers
>
> On Tuesday, 10 June 2014 06:31:28 UTC+10, Tim Martin wrote:
>>
>> On Monday, 9 June 2014 21:28:51 UTC+1, Tim Martin wrote:
>>>
>>>
>>> On Monday, 9 June 2014 20:44:08 UTC+1, Tim Martin wrote:
>>>>
>>>>
>>>> I'll go ahead and try to implement this using __neg__() to invert the
>>>> ordering.
>>>>
>>>>
>>> It's still pretty rough, but there's some code in
>>> https://github.com/timmartin/django/tree/order_by_expressions that
>>> appears to work. In particular, I haven't yet implemented the LowerCase and
>>> related functions (I have one, but it's just a test hack), but that should
>>> just be boiler-plate.
>>>
>>>
>> And I should have noted that I haven't implemented detection of negation
>> in contexts other than ORDER BY. It's not easy to do it cleanly with the
>> simple approach I've got at the moment. The code could just check that
>> get_ordering() returns ASC, but a) that's gross and b) it doesn't solve the
>> problem of having unary negative on a subexpression, which would get
>> ignored.
>>
>> Tim
>>
>  --
> 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/3f909f23-00a5-4bec-a21c-1333cec912b9%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/3f909f23-00a5-4bec-a21c-1333cec912b9%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: Terms for database replication

[Justin Holmes]

Aymeric +1


On Thu, Jun 5, 2014 at 5:54 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Everyone,
>
> It's exciting to see that much energy directed at Django! At the same
> time, it's sad to see it tragically misused.
>
> If you want to help, there are currently 124 pull requests on GitHub, 133
> patches on Trac and 38 new tickets, all needing a review.
>
> Any of these would be a better use of your time than this wording issue on
> which the core team has already made a final decision.
>
> Thank you,
>
> --
> Aymeric.
>
> [1] http://dashboard.djangoproject.com/
>
> --
> 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/0FB52B62-DA6B-4727-9549-B0FB911FB096%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: Terms for database replication

[Justin Holmes]

OK.  How about "canon" and "replica" ?


On Thu, Jun 5, 2014 at 2:59 PM, Tom Evans <tevans...@googlemail.com> wrote:

> On Thu, Jun 5, 2014 at 5:08 PM, Justin Holmes <jus...@justinholmes.com>
> wrote:
> > I don't want to devolve completely into an etymological circlejerk here,
> but
> > my sense is that "master" in the VCS sense is like "master key," rather
> than
> > describing the interpersonal relationship of involuntary servitude.
> >
>
> And in databases, it means the connection on which you can "master"
> records. Words have many meanings.
>
> --
> 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/CAFHbX1LbZACH7MPdmz7_M_x1pvhjH-d%2BjV%3Dya4S%2BVvTTGPheMA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: Terms for database replication

[Justin Holmes]

I don't want to devolve completely into an etymological circlejerk here,
but my sense is that "master" in the VCS sense is like "master key," rather
than describing the interpersonal relationship of involuntary servitude.


On Thu, Jun 5, 2014 at 11:53 AM, Malcolm Box <malc...@tellybug.com> wrote:

> FWIW, I think the main objection is to the word "slave", not to "master".
> Otherwise we'll be renaming the git branches soon...
>
> So "master" / "replica" would work.
>
> Malcolm
>
>
> On Thursday, 5 June 2014 16:26:07 UTC+1, Justin Holmes wrote:
>
>> I think I agree that "primary" is a bad choice.  Can you suggest
>> something other than master?  Something that will address the concerns
>> posed in the past two threads?
>>
>> I saw that someone suggested "leader" and "follower" - I haven't thought
>> through whether I find this more palatable.
>>
>>
>> On Thu, Jun 5, 2014 at 11:15 AM, Cal Leeming [Simplicity Media Ltd] <
>> cal.l...@simplicitymedialtd.co.uk> wrote:
>>
>>> For once, I'm going to +1 you Tom.
>>>
>>> Cal
>>>
>>>
>>> On Thu, Jun 5, 2014 at 2:52 PM, Tom Evans <teva...@googlemail.com>
>>> wrote:
>>>
>>>> Please revert this change as soon as possible.
>>>>
>>>> If the project has become so PC sensitive that the word "slave" is no
>>>> longer permitted to be uttered, then "replica" is an alternate term,
>>>> but "primary" is not.
>>>>
>>>> Have you ever set up "primary-primary replication"? No, neither have
>>>> I. Master-master replication is common, please do not take it upon
>>>> yourselves to re-program our vocabulary.
>>>>
>>>> I have a primary master, I do not have a primary primary!
>>>>
>>>> Cheers
>>>>
>>>> Tom
>>>>
>>>> --
>>>> 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/CAFHbX1%2BUa81AruHH7mRK9SyQCABQrprPDd7
>>>> sdTRrNN0_DpNPOg%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-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/CAHKQagGa1WE8yH2xpf0DrKv9i_m9%
>>> 2B6akcDTHexeUZmq%3DQZHUuA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CAHKQagGa1WE8yH2xpf0DrKv9i_m9%2B6akcDTHexeUZmq%3DQZHUuA%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>  --
> 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/0e3f8c99-38b6-424e-9f2c-7c0fe569b6a7%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0e3f8c99-38b6-424e-9f2c-7c0fe569b6a7%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: Terms for database replication

[Justin Holmes]

I think I agree that "primary" is a bad choice.  Can you suggest something
other than master?  Something that will address the concerns posed in the
past two threads?

I saw that someone suggested "leader" and "follower" - I haven't thought
through whether I find this more palatable.


On Thu, Jun 5, 2014 at 11:15 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> For once, I'm going to +1 you Tom.
>
> Cal
>
>
> On Thu, Jun 5, 2014 at 2:52 PM, Tom Evans <tevans...@googlemail.com>
> wrote:
>
>> Please revert this change as soon as possible.
>>
>> If the project has become so PC sensitive that the word "slave" is no
>> longer permitted to be uttered, then "replica" is an alternate term,
>> but "primary" is not.
>>
>> Have you ever set up "primary-primary replication"? No, neither have
>> I. Master-master replication is common, please do not take it upon
>> yourselves to re-program our vocabulary.
>>
>> I have a primary master, I do not have a primary primary!
>>
>> Cheers
>>
>> Tom
>>
>> --
>> 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/CAFHbX1%2BUa81AruHH7mRK9SyQCABQrprPDd7sdTRrNN0_DpNPOg%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/CAHKQagGa1WE8yH2xpf0DrKv9i_m9%2B6akcDTHexeUZmq%3DQZHUuA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAHKQagGa1WE8yH2xpf0DrKv9i_m9%2B6akcDTHexeUZmq%3DQZHUuA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

[no subject]

[Justin Holmes]

I want to retract my earlier statements regarding Jacob's (at the time,
seemingly hasty) reaction to Meira's comments. Two people have emailed me
off list about this matter, with one providing a quote of a horribly
bigoted passage from Meira:

'''
Black people refer to themselves "a person of color", and then even shorten
it: PoC. Isn't that a ridiculous acronym? If I were black, I would be
deadly offended if someone dared to call me "a person of color"! What's the
next step, "a person with skin color saturation level significantly higher
than of the majority of people living in european and asian part of the
world, as well as north and middle part of the north america, excluding
those who live in the south closer to Mexico and in Italy and in Caucasia
and/or spend a lot of time in the sun"?
'''

As such, I think that a warning and reminder about the CoC is entirely
appropriate.  I don't think that a ban is in order, but I now understand
Jacob's reaction.  My apologies, Jacob.

-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: "Master/slave terminology"

[Justin Holmes]

OK, I guess I'll weigh in on the substance.

The thing about "master" and "slave" is not (or at least not only) that
they refer to a sociopolitical configuration that is objectionable (for
example, the institutionally racist forms of slavery that have occurred in
many parts of the world throughout history).  It's that the interpersonal
dynamic of "master" and "slave" is itself abhorrent, absent its
implications or reminders.

On one hand, I am OK with regarding a machine (say, a database server) as
an utter servant.  I want a future in which machines are not granted the
leeways that humans have in the names of liberty and justice.  It's not
difficult to imagine a number of dystopic scenarios built atop a world in
which machine sovereignty is a trojan horse.

On the other hand, the words "master" and "slave," as they refer to
distributed database systems, are not actual a reference to the roles of
machines, but instead are a metaphor to describe our belief about how this
abstraction is to be regarded.  In this sense, "master" and "slave" are not
particularly accurate.  The other suggestions on these two threads all
communicate a more expressive metaphor for the way we want distributed
databases to work.

Finally (albeit perhaps tangentially), it is telling that, almost without
exception, detractors from this change regard slavery as either having
ended, being now illegal, or being something other than a really big deal.
Slavery, even in the United States, is not illegal.   The 13th amendment to
the US constitution specifically includes an exception to the ban on
slavery, allowing it "as a punishment for crime whereof the party shall
have been duly convicted."  There are currently more people - and more
people of color - living under slavery of this type now than at any point
prior to the civil war.  Of these, an abhorrently large number are subject
to this condition as "punishment for crime" which many if not all of us can
agree is not justly regarded as a crime at all.

If, in some small way, this shift in language can signal that we regard not
only the historical implications of the word "slave" but in fact the very
relationship structure described by "slave" and "master," we've done a good
thing.


On Wed, Jun 4, 2014 at 12:38 PM, Justin Holmes <jus...@justinholmes.com>
wrote:

> Although Meira's comments are disagreeable to me, and in at least one case
> clearly factually incorrect, she has not come close to violating the code
> of conduct.  Nor has she been particularly disrespectful.  To even talk
> abut banning her is absurd, particularly in a thread whose subject is
> developing inclusive language.
>
>
> On Tue, May 27, 2014 at 1:46 PM, Jacob Kaplan-Moss <ja...@jacobian.org>
> wrote:
>
>> Meira, your position has been made abundantly clear, and now your
>> behavior is treading dangerously close to the line. I'll remind you and
>> others of our community's code of conduct (
>> https://www.djangoproject.com/conduct/), which specifically requires
>> that we be welcoming, friendly, patient, and respectful. Meira, you're not
>> doing a great job on any of these, specifically the respect.
>>
>> Again you've made your point, and thank you for it. We all know where you
>> stand. Now it's time for you to withdraw from this thread.
>>
>> I don't want to ban you from the list, but I will if I need to.
>>
>> Jacob
>>
>>
>> On Tue, May 27, 2014 at 12:21 PM, Meira <poo...@gmail.com> wrote:
>>
>>> I meant legally, of course. It is illegal now. Should we ban the word
>>> "drugstore" too, maybe?
>>>
>>> I previously pointed out that I'm aware of the fact that there still is
>>> slavery in one form or another. I also mentioned that I don't believe this
>>> change made django more attractive for any of the current slaves.
>>> Not even single slave's life was in any way improved by a free person
>>> complaining about a server being called "slave".
>>>
>>>
>>>
>>>
>>> On Wednesday, May 28, 2014 12:16:27 AM UTC+7, Alex_Gaynor wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 27, 2014 at 12:14 PM, Meira <poo...@gmail.com> wrote:
>>>>
>>>>> I think it makes more sense to count reasonable arguments of both
>>>>> sides, not the people who thumb up in the comments (by the way, those who
>>>>> thumb up are mostly Americans, isn't that discrimination?)
>>>>> If using the word "slave" is immediately associated with racism, it's
>>>>> a sign that we might have 

Re: "Master/slave terminology"

[Justin Holmes]

gt;>> would consider this whole episode as being entirely worth it.
>>>>>
>>>>> Not that I think it's a sustainable strategy in the long term, of
>>>>> course.
>>>>>
>>>>> 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-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/4da37237-adb4-49bd-b710-
>>>> 280dda186aea%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/4da37237-adb4-49bd-b710-280dda186aea%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> Alex
>>>
>>> --
>>> "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/6b9c68a2-01e2-433f-a442-16d4bd8ba51e%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/6b9c68a2-01e2-433f-a442-16d4bd8ba51e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAK8PqJEgSJAUgT0FbTbxh9%3D%3DZG0gzjZ2qaBSWdGARYiaPoJpFw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAK8PqJEgSJAUgT0FbTbxh9%3D%3DZG0gzjZ2qaBSWdGARYiaPoJpFw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: Should there be a "is" comperator: {% if A is B %}?

[Justin Holmes]

I think I'm +1.  This seems to add some signal with zero noise.
On Apr 11, 2014 4:35 AM, "Gregor Müllegger"  wrote:

> Casting to strings would make this example work. But will break in other
> cases:
>
> dict((key, str(val)) for key, val in {'value': None}.items())
>   => 
>
> I don't want to say that this problem is impossible to solve without a
> "is" check in the templates, I only want to point out that this basic
> comparison that is very handy in python on many ocassions is not available
> in the template. And having something like this in core might just make the
> template language a bit rounder and nicer to use for pythonistas.
>
> · Gregor ·
>
>
> 2014-04-11 7:44 GMT+02:00 Łukasz Rekucki :
>
>> On 11 April 2014 01:11, Gregor Müllegger  wrote:
>> > Hi,
>> >
>> > thanks for your input. Unfortunatelly this would fail for int(0):
>>
>> Not if you encode all values to strings before passing to the
>> template, so it's "0" instead of 0.
>>
>> >
>> > {'value': 0} => 
>> >
>> > Gregor
>> >
>> >
>> > 2014-04-10 11:41 GMT+02:00 Tino de Bruijn :
>> >
>> >> Wouldn't this be easier?:
>> >>
>> >> {'required': "", 'name': 'fieldname'} => > name="fieldname"
>> >> />
>> >>
>> >> {% for name, value in attrs.items %} {{ name }}{% if value %}="{{ value
>> >> }}"{% endif %}{% endfor %}
>> >>
>> >>
>> >> Tino
>> >>
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> 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/CAEZs-EL%2BNqWuo-F6AkAWCBb5rn_7GKGXkfD35uyfF%2Bqbvss5Sw%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/CALjSGCNDMC1q7LhamQaf%3D9jEW0bXPn5gdpmDL88dVQgKsNb__Q%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/CAMGywB7SbmgLE-Tp0qDw6kUsOJFi6%3D-32RMGkq_zn-kd%2Bh%3DeqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #9?

[Justin Holmes]

I didn't mean to suggest that it was nefarious.  It's just that that ticket
had some... sentimental value.  ;-)


On Sat, Feb 15, 2014 at 6:49 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> There isn't anything nefarious going on here; we delete tickets
> occasionally. It's usually due to spam. There's a lot of deleted tickets in
> the 20k range.
>
> Yours,
> Russ Magee %-)
>
> On Sun, Feb 16, 2014 at 7:37 AM, Justin Holmes <jus...@justinholmes.com>wrote:
>
>> It appears that Ticket #9 has been deleted?  Anybody know why?
>>
>> https://code.djangoproject.com/ticket/9
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>> --
>> 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/CAMGywB4MExcuO_MR5HRi6pHf6XLD65tw_p1YXrHedV9Pa%3DCF_Q%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq849T25R7F3U7yWFHYdkSzQbnL6%2Bp6r23_cH%3DOUjUKVYwZw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
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/CAMGywB43TywVxdzk5Xqedbt_KO2mjo8SM-115mmQz3wuaWBh4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ticket #9?

[Justin Holmes]

It appears that Ticket #9 has been deleted?  Anybody know why?

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

-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

-- 
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/CAMGywB4MExcuO_MR5HRi6pHf6XLD65tw_p1YXrHedV9Pa%3DCF_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Question about new tests

[Justin Holmes]

Florian,

Let me cobble together a demonstration and what I'm talking about; I think
I can more easily illuminate things that way.


On Tue, Sep 17, 2013 at 5:31 PM, Florian Apolloner <f.apollo...@gmail.com>wrote:

> Hi Justin,
>
> many core developers haven't been at DjangoCon US, so would you mind to
> summarize a few things like: What is the roadmap, how do you plan to tackle
> things; who is involved + whatever else you think would be nice to know for
> someone who more or less heard the first time of this from your mail here.
>
> Thanks & regards,
> Florian
>
>
> On Tuesday, September 17, 2013 7:55:08 PM UTC+2, Justin Holmes wrote:
>>
>> I'm working on the #unsetting project (ie, making all of Django's
>> internals work without having to import the settings global).
>>
>> We have two key areas that now seem to work without running settings:
>> mail and templating.
>>
>> I want to demonstrate these with tests.  Where shall I put these tests?
>>
>> 1) Alongside the respective tests for these features (ie, tests.mail)?
>> 2) As a regression test (ie, also in tests.mail, but demonstrating that
>> the inane errors no longer appear)
>> 3) Alongside the unsetting config?
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Question about new tests

[Justin Holmes]

I'm working on the #unsetting project (ie, making all of Django's internals
work without having to import the settings global).

We have two key areas that now seem to work without running settings: mail
and templating.

I want to demonstrate these with tests.  Where shall I put these tests?

1) Alongside the respective tests for these features (ie, tests.mail)?
2) As a regression test (ie, also in tests.mail, but demonstrating that the
inane errors no longer appear)
3) Alongside the unsetting config?

-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: proposal: post-collectstatic signal

[Justin Holmes]

Ptone: Coldbrew already uses a templatetag for development, but for
production, we want people to be able to have the collectstatic experience
and simple find collected coffee as compiled JS in their static directories.

As you suggest, I have reluctance about Bruno's solution.  Also, I'd be
concerned about the message sent to future generations by amending the docs
to read, "ensure that 'coldbrew' appears after 'staticfiles' in your
INSTALLED_APPS tuple."

Wrapping collectstatic is an enormously simple and elegant solution - to my
knowledge, this hadn't even crossed our minds at slashRoot.

Janis: I hadn't noticed that we can obtain a list of collected paths from
post_process - this is wonderful!  This seems like a winning solution at
least for obtaining a list of directories in which we need to search for
unbrewed coffee.  Come to think of it - is this the best way to do this?
Or is there a STATICFILES_STORAGE agnostic way of obtaining an
authoritative list of staticfiles locations?

My only concern is that we'll limit our audience by requiring users to use
a specific STATICFILES_STORAGE.  What if they're already using a custom one?




On Mon, Nov 12, 2012 at 3:08 PM, Jannis Leidel <lei...@gmail.com> wrote:

>
> On 11.11.2012, at 17:09, Justin Holmes <jus...@justinholmes.com> wrote:
>
> > My sense is that there are a growing number of use cases, but the one
> that I currently have in mind is for django-coldbrew.  I want to be
> able to compile all the coffeescript in a project during the collectstatic
> process.  Currently, we have a management command, "collect_coldbrew" - but
> I'd like to allow users to have this occur automatically during
> collectstatic.
>
> The collectstatic command calls a method "post_process" method [1] of the
> staticfiles storage if it exists and passes a list of file paths that have
> been collected [2].
>
> In other words, hooking into collectstatic is as easy as writing an own
> subclass of StaticFilesStorage (or whatever storage backend you've set
> STATICFILES_STORAGE) and implement the method.
>
> Would that suffice for your use case?
>
> Jannis
>
> 1:
> https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.StaticFilesStorage.post_process
> 2:
> https://github.com/django/django/blob/master/django/contrib/staticfiles/management/commands/collectstatic.py#L116-127
>
> > I'm not sure if the best timing for the signal is at the end of the
> complete collectstatic process or at the end of each iteration (ie, one
> signal for each static directory that django finds).
> >
> >
> > On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor <alex.gay...@gmail.com>
> wrote:
> > What's the use case?
> >
> > Alex
> >
> >
> > On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes <jus...@justinholmes.com>
> wrote:
> > Currently, our only built-in management signal is post-syncdb.
> >
> > I propose (and, notwithstanding objection, will build)
> post-collectstatic.
> >
> > Is this reasonable?  Is there another, less invasive way to hook logic
> into collectstatic?
> >
> >
> > --
> > Justin Holmes
> > Chief Chocobo Breeder, slashRoot
> >
> > slashRoot: Coffee House and Tech Dojo
> > New Paltz, NY 12561
> > 845.633.8330
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
> >
> >
> > --
> > "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
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
> >
> >
> > --
> > Justin Holmes
> > Chief Chocobo Breeder, slashRoot
> >
> > slashRoot: Coffee House and Tech Dojo
> > New Paltz, NY 12561
> > 845.633.8330
> >
> > --
> > You received this message because y

Re: proposal: post-collectstatic signal

[Justin Holmes]

My sense is that there are a growing number of use cases, but the one that
I currently have in mind is for django-coldbrew.  I want to be able to
compile all the coffeescript in a project during the collectstatic
process.  Currently, we have a management command, "collect_coldbrew" - but
I'd like to allow users to have this occur automatically during
collectstatic.

I'm not sure if the best timing for the signal is at the end of the
complete collectstatic process or at the end of each iteration (ie, one
signal for each static directory that django finds).


On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:

> What's the use case?
>
> Alex
>
>
> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes <jus...@justinholmes.com>wrote:
>
>> Currently, our only built-in management signal is post-syncdb.
>>
>> I propose (and, notwithstanding objection, will build)
>> post-collectstatic.
>>
>> Is this reasonable?  Is there another, less invasive way to hook logic
>> into collectstatic?
>>
>>
>> --
>> Justin Holmes
>> Chief Chocobo Breeder, slashRoot
>>
>> slashRoot: Coffee House and Tech Dojo
>> New Paltz, NY 12561
>> 845.633.8330
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
>
> --
> "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
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

proposal: post-collectstatic signal

[Justin Holmes]

Currently, our only built-in management signal is post-syncdb.

I propose (and, notwithstanding objection, will build) post-collectstatic.

Is this reasonable?  Is there another, less invasive way to hook logic into
collectstatic?

-- 
Justin Holmes
Chief Chocobo Breeder, slashRoot

slashRoot: Coffee House and Tech Dojo
New Paltz, NY 12561
845.633.8330

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

Re: GitHub migration done!

[Justin Holmes]

Adrian,

Thank you.  Well done.  Awesome.  :-)

On Fri, Apr 27, 2012 at 11:08 PM, Adrian Holovaty <adr...@holovaty.com> wrote:
> On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty <adr...@holovaty.com> wrote:
>> We're going to do the migration to GitHub today. This means we'll no
>> longer be committing code to our Subversion repository. Committers,
>> please hold off on making commits until the migration is done.
>
> OK, it's live!
>
> https://github.com/django/django
>
> A few quick points (though this definitely deserves a more in-depth writeup):
>
> * I renamed the old (mirror) repository to
> https://github.com/django/django-old. We had talked about deleting it
> outright to avoid confusion, but I realized at the last minute that
> doing so would have deleted all the pull requests. I didn't want to
> throw all of that out, and I think we can figure out a way to use
> those pull requests in the new repository.
>
> * I only migrated trunk (now called "master"), rather than including
> all of the branches. This was the result of a bunch of discussion on
> IRC with Brian R., et al. The thinking is that it kept the migration a
> lot cleaner/simpler, and we can always add branches later. Of course,
> we'll need to create the latest release branches. Otherwise, we can
> consider the SVN branches on an individual basis.
>
> * As expected, all forks of the old repository are now broken. Can
> somebody volunteer to write some documentation on how to upgrade your
> old fork to use the new upstream repo (rebase? simple patch?)?
>
> * We're going to keep the Subversion repository around indefinitely,
> but it'll no longer be updated.
>
> * We're going to keep using Trac for tickets, but pull requests on
> GitHub are also welcome.
>
> * Clearly there are lots of bits of process that need to be updated
> now, from the django-updates mailing list to our "contributing"
> documentation, etc. We'll take care of all of that in the coming days,
> and we should all expect some degree of confusion and unsettlement in
> the community. That's totally fine, and we'll get through it. :-)
>
> * Finally, big thanks to the folks on IRC today who helped me through
> the process and contributed good ideas.
>
> I'm planning to write up a blog post on how the process went, for the
> benefit of the five open-source projects still using Subversion.
>
> Adrian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Change to order of Session creation in 1.4?

[Justin Holmes]

I have a signal hook set on user_login.  I use this in order to
get_or_create a SessionInfo object, which I use to keep track of data
about users who may login from more than one computer at the same
time.

in 1.3, the Session object for the login that is taking place had
already been created at the time of the hook execution.

However, In 1.4, Session.objects.all() yields empty during the hook execution.

Am I seeing things?  Or did this change?

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

Http404 and process_exception

[Justin Holmes]

Heretofore, I had always believed that Http404 did not cause Middleware
process_exception() to be run.  Am I right in this thinking?

I have a get_object_or_404 that, when the object in question isn't found,
is running process_exception.

-- 
Justin Holmes

Instigator, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

LiveServerTestCase

[Justin Holmes]

Julien, et. al.,

Seriously.  Thank you.  Amazing.



-- 
Justin Holmes

Head Instigator, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

django-deeper

[Justin Holmes]

In response to the recent discussion of SOPA on the django-dev list
(and to the recurring phenomenon of having no clearly defined space to
congregate to discuss "deeper" issues), I have started a new google
group, django-deeper.

As a relative newcomer to the django community, I have been
overwhelmed by the awesome vibes.  Djangocon 2011 was one of the best
conferences (probably top 5 even) that I've ever been to.

>From the very first peek at the project, it's clear that django has a
much sharper focus on community building than is typical for a
software project.  The emphasis and effort on documentation, for
example, sends a strong signal that "this is not just a piece of
software, it's a group of passionate people."  The mature and
open-minded atmosphere of the django IRC presence also suggests this.

As the django community expands in breadth and in depth, we need a way
to ensure that our underlying aspirations - expressed sometimes in the
form of python code but sometimes as political, philosophical, or
psychological prose, are likewise cultivated.  My hope is that
django-deeper will provide a forum for those of us who welcome growth
in this direction.

http://groups.google.com/group/django-deeper

-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: SOPA bill question

[Justin Holmes]

Yep, there's no doubt that having these kinds of discussions on the
dev list (which already struggles at times to keep a good signal /
noise ratio) is not the way.

However, it was clear at djangocon (and is also clear in the various
django IRC channels) that:

1) Many django developers are politically conscious and active, and

2) Many django developers view their participation in the django
project *as a political act*.

Where, then, can we gather to discuss the social and political issues
facing our community, and the social and political implications of the
various decisions that we make?

To my knowledge, there isn't currently a "proper forum" for this
discussion.  I'd like to create and cultivate one if I can get the
proper guidance from the core team.



On Mon, Dec 26, 2011 at 10:18 PM, Paul McMillan <p...@mcmillan.ws> wrote:
> While this bill certainly merits discussion, and may indeed be related
> to sites created with and using Django, this forum is not the place
> for it. Please do not continue this thread here.
>
> -Paul
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Feature proposal: models.CALL_DELETE or effective equivalent

[Justin Holmes]

"hacks, signals, and/or patches"

One of these things is not like the other.

The signals framework is made for precisely for cases like the one you
describe.  Why do you compare it to hacks / patches?

Your signal can be utterly DRY and you can write unit tests for it
(although, if you are using a template in the callable, you may fall
prey to the problem I tried to patch in #17032).

In every way I am currently able to contemplate, using a signal is
more straightforward and decoupled than the solution you propose.  I
may well be missing something; please point it out if that's so.


On Sun, Dec 4, 2011 at 11:28 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> Or is your main objection having to branch against the specific
>
> Simply put, there should be an *optional* way to ensure a model's
> *explicitly* defined delete behavior is honored without having to
> write hacks, signals, and/or patches of any kind (ie, make it DRY, and
> therefore less error-prone). This seems like common sense, so I really
> don't know how much more I can clarify the topic.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Feature proposal: models.CALL_DELETE or effective equivalent

[Justin Holmes]

Doesn't using the pre_delete signal accomplish this?

Or is your main objection having to branch against the specific
models, leading to the coupling you are talking about?  It surely
solves the monkey-patching problem, though, no?



On Sun, Dec 4, 2011 at 3:14 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> Did my last post answer the question you had, Adrian?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Forbiden 403 error

[Justin Holmes]

Hello there.  You've posted to django-developers which is a mailing
list of development of the django project itself.  For help using
django, please post to django-users.

On Wed, Nov 16, 2011 at 1:25 PM, Djano_newb <zamboni_...@yahoo.com> wrote:
>
> I am new to both python and Django but I have been programming for more than
> 20 years so I am teaching myself this stuff.  I came across an old training
> video that I have been going through.  This training has you develop a
> website that can create web pages.  I got everything right so far but I just
> got to the point where you are to save off your changes to create a new file
> and I am getting the 403 Forbidden error associated with a POST to my
> connection.  The error specifically states "CSRF token missing or
> incorrect."
>
> Now I am currently reading through this stuff on the Django web site and I
> find that you must have it at the top of your "views" but can someone
> explain in more plain language why this isn't on by default and what the
> problem really is here?  In reading the info on the Django site it seems
> backwards so I must be missing something.  When I read it, it sounds like
> you have to add this to "gain" the protection not remove it.  What I think I
> am seeing is my system is not allowing my browser to write new files so I
> have the protection by default and I need to add this stuff in order to
> remove the protection.  That makes sense to me but seems backwards from what
> I read on the Django site.  I am very confused by this.  Any help would be
> appreciated.
> --
> View this message in context: 
> http://old.nabble.com/Forbiden-403-error-tp32856616p32856616.html
> Sent from the django-developers mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Django application instances

[Justin Holmes]

Chris,

Your message comes at a time of frequent discourse over the matter of
apps and pluggability.  There's no doubt in my mind that a desire
exists in the django community for this functionality, so I'm
certainly +1 on your creation of a patch.  There's no single ticket
around which this matter has coalesced - creating a new ticket is
probably a good approach.

I assume you have already checked out the main wiki page on pluggable
apps at https://code.djangoproject.com/wiki/ReusableAppResources - a
link to your proposal may be appropriate.



On Sun, Nov 6, 2011 at 2:40 PM, Chris Northwood <cnorthw...@gmail.com> wrote:
> Hi there,
>
> My name's Chris Northwood and I'm a core contributor to the Molly
> Project (http://mollyproject.org/), which is a mobile portal framework
> built on top of Django. We're an open source project but we currently
> think we're doing quite a few things that are "non-core" for us, and
> we'd like to push back upstream into the Django project.
>
> One of these things are multiple application instances. We've built a
> fairly straight-forward way to instantiate multiple instances of the
> same app (with self-contained configuration) in the settings.py, e.g.,
>
> APPLICATIONS = [
>
> Application('molly.apps.weather', 'oxweather', 'Oxford Weather',
>    location_id = 'bbc/25',
>    provider =
> Provider('molly.apps.weather.providers.BBCWeatherProvider',
>        location_id = 25,
>    ),
> ),
>
> Application('molly.apps.weather', 'lonweather', 'London Weather',
>    location_id = 'bbc/8',
>    provider =
> Provider('molly.apps.weather.providers.BBCWeatherProvider',
>        location_id = 8,
>    ),
> ),
>
> ]
>
> INSTALLED_APPS += extract_installed_apps(APPLICATIONS)
> ROOT_URLCONF = 'molly.urls'
>
> This defines two apps of the molly.apps.weather reusable Django app,
> one with a URLconf under /oxweather/ and one under /lonweather/.
> Depending on the URL accessed, the (class-based) views inside the app
> then have access to a self.conf attribute which they can use when
> querying the database (or whatever) to deliver different behaviour
> based on the class, i.e., inside our view
>
> current_weather =
> Weather.objects.get(location_id=self.conf.location_id)
>
> We use this fairly extensively, and there are a number of non-trivial
> examples in our codebase too.
>
> The URLconf is automatically generated by the molly.urls module, and
> we also have the ability to annotate our class-based views using a
> custom @url annotator so the URLconf for the application is also
> automatically generated (to us it makes sense to keep the patterns in
> the same place as the view!)
>
> My question is, would the Django community at large find this
> functionality useful, i.e., is it worth us working to break this
> functionality out of our libraries and then provide a patch to you
> guys? It's certainly non-trivial, and I wouldn't want to waste effort,
> and I think this is functionality that could be useful for others.
>
> Regards,
>
> Chris Northwood
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Corporate CLA

[Justin Holmes]

I am interested in getting the SlashRoot membership all filed with CLA's.

However, people who work on django at SlashRoot aren't "employees" -
they're members.  Can we simply change the language of the CLA or are
the legal wranglings more complex than that?

Might it be simpler for each of us to simply fill out the individual
form?  Or does that not cover the proper basis of members be able to
work on django on paid company time?

-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

TEMPLATE_DIRS in django.contrib.auth.tests.views

[Justin Holmes]

contrib.auth.tests.views line 28 overrides settings.TEMPLATE_DIRS
causing tests to fail for signal hooks that use templates in locations
specified in settings.TEMPLATE_DIRS.

Is this a bug?  I can't immediately see the reason for overriding
here.  I understand that the test runner needs its own templates, but
why not just add this location to the tuple?  At very least, it causes
in an unexpected result.

-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: contrib.sessions test oddities

[Justin Holmes]

We figured out the phenomenon that triggered this problem:

The djangobb middleware was saving items to the cache using integers
(user ids) as the key and True as the value.  Obviously this is an
abhorrent practice in its own right both for disambiguation and
security.

We have submitted a patch (which has since been committed) which
generates a (hopefully) helpful fail message instead of raising
AttributeError.

Additionally, this practice has explained the strange timing issue:
The key in the cache expired after 15 seconds.

However, at least two questions remain:

1) In response to Stephen's point: I understand that the cached_db
backend reads from localmem by default, by why isn't .set() being run
on the db in the test case?  .set() does in fact get run in the
regular use of this app, yet it is never tested by our test suite.

2) What is the canonical style practice for cache keys?  Where does it
need to be documented?  Is the use of a naked integer as a key in fact
contrary to our guidelines?  It certainly needs to be, right?  If so,
shall we raise a warning if in fact this happens?  I'd be concerned
that testing the incoming cache key might be unduly expensive for very
cache-heavy projects and that the test itself will punish those who do
follow the guidelines.


On Tue, Oct 4, 2011 at 9:11 PM, Stephen Burrows
<stephen.r.burr...@gmail.com> wrote:
> Hi,
>
> It sounds like you're looking at tests for
> django.contrib.sessions.backends.cached_db. If that is the case, then
> it's not unusual that you would end up calling the LocMem cache
> backend. The cached_db session backend does all of its reads from the
> cache, only falling back to the database sessions if the key is not
> found in the cache. So, unless you define a different cache backend in
> your settings.py file, the cached_db session backend will use the
> LocMem cache backend.
>
> That doesn't necessarily mean you haven't run into a problem, of
> course. But it may explain some of what you're experiencing.
>
> Best,
> Stephen Burrows
>
> On Oct 4, 9:22 pm, Justin Holmes <jus...@justinholmes.com> wrote:
>> I posted this message on -users today, but at PaulM's urging, I'm
>> bringing it over here out of concern that it may reflect a bug in the
>> contrib.sessions test suite.
>>
>> Here's the original message from -users (some -dev only notes follow) :
>>
>> I am having a problem with contrib.sessions.tests.test_valid_key (line
>> 159).  It's a mixin which in the failure case is mixed with
>> CacheDBSessionTests.
>>
>> The test raises:
>>
>> "AttributeError: 'bool' object has no attribute 'get'"
>>
>> The error is actually raised by session.save() on 164.
>>
>> Stepping inward reveals that sessions.backends.cached_db (line 18)
>> sets data thusly:
>>
>> data = cache.get(self.session_key, None)
>>
>> QUESTION #1 (maybe more suited for django-dev?): If I step in, I find
>> that debugging core.cache.backends.locmem.LocMemCache.get(), which is
>> odd since the TestCase is CacheDBSessionTests.  Why is it testing
>> LocMemCache and not core.cache.backends.db.DatabaseCache?
>>
>> In this case, self.session_key is 1, and indeed the cache has a
>> pickled "True" for the key 1.  In fact, during the course of debugging
>> core.cache.backends.locmem.LocMemCache.get(), we have found that in
>> every case during which the testrunner hits this method, 1 is a key
>> for pickled True.
>>
>> QUESTION #2: Why is the key 1 set to a pickled True?
>>
>> In this case, that True ends up being returned in
>> contrib.sessions.backends.base.SessionBase.get() (line 64).
>>
>> Thus, of course an error is raised.  We are unable to understand why
>> the key 1 is set to pickled True in the locmem backend.
>>
>> NOW THE STRANGE PART:
>>
>> Iff we step in with a debugger and wait for > 3 seconds or so, the
>> method no longer returns True and instead returns an empty dict.  In
>> this case, the test passes!
>>
>> We are baffled.  Is this possibly an underlying race condition or
>> hotel room scenario (http://stackoverflow.com/questions/6441218)?
>>
>> [END DJANGO-USERS MESSAGE]
>>
>> I also want to point a few additional things here on the dev list:
>>
>> *We have tried this on two different computers with OSX and Linux and
>> we encounter the timing issue either way, every time.
>> *We put a breakpoint on django.core.cache.backends.db.get() (line 38)
>> which was never hit during the course of the sessions tests.
>> *We were hoping to find that the test runner hit one backend if we
>> didn't wait in state and another if we did.  Howeve

contrib.sessions test oddities

[Justin Holmes]

I posted this message on -users today, but at PaulM's urging, I'm
bringing it over here out of concern that it may reflect a bug in the
contrib.sessions test suite.

Here's the original message from -users (some -dev only notes follow) :

I am having a problem with contrib.sessions.tests.test_valid_key (line
159).  It's a mixin which in the failure case is mixed with
CacheDBSessionTests.

The test raises:

"AttributeError: 'bool' object has no attribute 'get'"

The error is actually raised by session.save() on 164.

Stepping inward reveals that sessions.backends.cached_db (line 18)
sets data thusly:

data = cache.get(self.session_key, None)

QUESTION #1 (maybe more suited for django-dev?): If I step in, I find
that debugging core.cache.backends.locmem.LocMemCache.get(), which is
odd since the TestCase is CacheDBSessionTests.  Why is it testing
LocMemCache and not core.cache.backends.db.DatabaseCache?

In this case, self.session_key is 1, and indeed the cache has a
pickled "True" for the key 1.  In fact, during the course of debugging
core.cache.backends.locmem.LocMemCache.get(), we have found that in
every case during which the testrunner hits this method, 1 is a key
for pickled True.

QUESTION #2: Why is the key 1 set to a pickled True?

In this case, that True ends up being returned in
contrib.sessions.backends.base.SessionBase.get() (line 64).

Thus, of course an error is raised.  We are unable to understand why
the key 1 is set to pickled True in the locmem backend.

NOW THE STRANGE PART:

Iff we step in with a debugger and wait for > 3 seconds or so, the
method no longer returns True and instead returns an empty dict.  In
this case, the test passes!

We are baffled.  Is this possibly an underlying race condition or
hotel room scenario (http://stackoverflow.com/questions/6441218)?

[END DJANGO-USERS MESSAGE]

I also want to point a few additional things here on the dev list:

*We have tried this on two different computers with OSX and Linux and
we encounter the timing issue either way, every time.
*We put a breakpoint on django.core.cache.backends.db.get() (line 38)
which was never hit during the course of the sessions tests.
*We were hoping to find that the test runner hit one backend if we
didn't wait in state and another if we did.  However, as noted in the
point above, that doesn't appear to be the case (unless we're missing
something about the way the backends are implemented, which is
possible)
*Thinking that using cached_db for the backend might result in .get()
being used only in LocMem, we also put a breakpoint in
backends.db.set(), thinking that both were going to be set.  This
breakpoint was also never hit during the course of the sessions tests.
*The commit comment, by Russell Keith-Magee, seems like it is likely
related: "Fixed #15026 -- Added cleanup to the invalid key session
tests; when using Memcached as a cache backend, the cache-backed
session backends would fail on the second run due to leftover cache
artefacts. Thanks to jsdalton for the report and patch."
*#15026 seems to describe a substantially different problem, but it is
possible that the root cause is similar or the same: that unflushed
material in the cache persists between tests.

We encountered this issue at DiscSpace, which is cool enough to let
freelancers work on issues in the django internals on company time if
we encounter them.


-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: deprecation vs removal

[Justin Holmes]

or PendingRemoval?

On Mon, Oct 3, 2011 at 9:56 PM, Tai Lee <real.hu...@mrmachine.net> wrote:
>
>
> On Oct 4, 11:17 am, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>> I'm completely agreed that the 'soft' deprecation is useful. I'm just
>> complaining about the ambiguity in the language: "We're deprecating
>> this feature by marking it PendingDeprecation...".
>
> What about just changing "PendingDeprecation..." to
> "SoftDeprecation..." or "QuietDeprecation..."? It's not really pending
> deprecation. It is deprecated already, but we just don't loudly
> complain (yet) if people haven't updated their code immediately.
>
> Cheers.
> Tai.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: API for introspecting models

[Justin Holmes]

Very interesting / exciting.  I'm definitely +1 on this project - I
definitely have some of the "break hard" projects that Russell is
talking about and I'd love to have a more straightforward and
sustainable way to do introspection.

Let me know how I can help.

On Fri, Sep 23, 2011 at 10:47 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Fri, Sep 23, 2011 at 6:10 PM, sebastien piquemal <seb...@gmail.com> wrote:
>>> So - it's one of those things that *should* be documented and
>>> fomalized; it's just waiting on someone with the spare time to do the
>>> job.
>>
>> Sounds good ! Any estimation on how big is the cleaning task ? I know
>> documentation task can go forever :)
>
> About as long as this piece of string that I'm holding. Oh, wait - you
> can't see the string? Let me hold it up for you... :-)
>
> Seriously -- I can't really answer this. It's not a completely trivial
> task, but it's not complex on the order of "multi-db" or "no-sql
> support" either. The first step really is an audit -- a rough cut at
> documenting everything that is there at the moment. Once we have that,
> we can look at how the existing API is being used, and evaluate the
> cleanup opportunities.
>
> Once that's done, we'll be in a much better position to evaluation how
> much work is involved.
>
>> And what about the extra features I suggested ? A more user-friendly
>> way to get all -data- fields (including m2m, excluding pointers), an
>> easy way to get the name of the pk field of the first parent.
> ...
>> Or did I miss some methods/properties from the _meta API ?
>
> Off the top of my head, I can't answer this. It's *possible* that
> there might be some way to do this, but I'd need to go digging to work
> out for sure, and I can't refer to the documentation to find out
> easily :-)
>
> However, I wouldn't be at all surprised if it isn't possible. The
> _meta API is mostly designed for Django's own internal needs, and
> Django needs to make a very clear distinction between fields and
> m2m's, forward and reverse fields, and so on; hence the distinctions
> that exist in the current API. "Iterating over all fields" doesn't
> make much sense from an internal perspective, because different types
> of fields need to be handled differently. Similarly, the "hidden" _ptr
> fields might not be important from a public visibility perspective,
> but they're very important from an internal perspective.
>
> That said, just because Django doesn't have a use for the API doesn't
> mean it wouldn't be useful. If you can propose a clean way to augment
> the _meta API to provide this sort of capability, I don't see any
> fundamental reason why it shoudn't be included.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: is it time to start deprecating parts of contrib

[Justin Holmes]

It depends how surgical this discussion is; if we're at the model
level, then it's pretty clear that we need to reinvent auth.User and
deprecate functionality accordingly.

I'm not hearing anyone say that contrib.auth is an undesired battery
tout court, but the sentiment that it fails to "get out of the way" is
basically universal, and has been for some time.

A small group of us began a brainstorm on day 2 of the sprints in
Portland.  It is ongoing here:

https://code.djangoproject.com/wiki/UserHasABadMotivator

On Tue, Sep 20, 2011 at 12:51 PM, Carl Meyer <c...@oddbird.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/20/2011 06:13 AM, ptone wrote:
>> At DjangoCon.us there was positive reception to Jacob's thoughts that
>> Django core could be leaner - people liked the kernel analogy.
>>
>> Talk of reducing contrib has been around a long time.
>>
>> Per policy, it takes 3 minor versions to remove something from Django
>> - near as I can tell, a PendingDeprecation warning could be reversed
>> if there was a large change of opinion.
>>
>> There is perhaps no more humorous a line in all of the Django docs
>> than this:
>>
>> "Databrowse is very new and is currently under active development. It
>> may change substantially before the next Django release."
>>
>> My top nominations for contrib apps to go away are:
>>
>> Databrowse
>> webdesign
>> formtools
>
> I would be +1 on starting with deprecation of both databrowse and
> webdesign, -0 on formtools at this point for the same reason Jannis
> mentioned; it is actually actively maintained and used, and recently got
> some major improvements. In the abstract I do think that formtools is a
> fine candidate to be an external app rather than live in contrib, I just
> think we may as well start with the lower-hanging fruit here.
>
> Databrowse could easily be spun off into an external app if anybody
> cared to maintain it.
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk547rMACgkQ8W4rlRKtE2cLvwCg6x/sCROjtIG6GBBFuQljV4pw
> u+IAoMrXUYg7MLr61CNKPRYTfhPFIZWu
> =6hxI
> -END PGP SIGNATURE-
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: RFC: "universal" view decorators

[Justin Holmes]

James,

Your case seems to rest on what is "natural" - both in terms of how to
modify existing control structures and as a general goal that our
resulting syntax must "feel natural."

I submit that the way that will "feel natural" is to simply allow
decoration of any view, be it a class or a function, with the
decorator whose name describes precisely the functional modification.
This is simple to read, easy to remember, and, frankly, DRY.


On Fri, Sep 16, 2011 at 7:27 PM, Donald Stufft <donald.stu...@gmail.com> wrote:
> unittest.skip isn't a Mixin, it turns the class into an exception and raises
> it.
> django.test.utils.override_settings is a mixin and it's terrible, it
> dynamically creates a new subclass, and overrides 2 methods. It's magic and
> more complex then need be.
>
> On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote:
>
> On Fri, Sep 16, 2011 at 9:47 PM, James Bennett <ubernost...@gmail.com>
> wrote:
>
> We have the following constraints:
>
> 1. Django supports class-based views.
>
> 2. Django supports function-based views (ultimately these are the same
> thing, which is that Django supports anything as a 'view' so long as
> it's callable, accepts an HttpRequest as its first positional argument
> when being called and either returns an HttpResponse or raises an
> exception).
>
> 3. The natural way to add processing in/around a class is subclassing
> and either overriding or mixing in.
>
> 4. The natural way to add processing in/around around a function is
> decorating.
>
> Any solution to this needs to address those constraints, and allow
> code to look and feel natural.
>
> Based on that, some arrangement which allows the same basic logic to
> exist in a "mixin" (I dislike that word) for classes and a decorator
> for functions seems most appropriate, even if it does mean having two
> ways to do things -- that's a distinction I think we can live with, as
> people will appreciate that it doesn't result in strange-looking code.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
> I agree with all your points, except #3, I think it's an over
> simplification.  There's another way to change a class: class decorators.
>  And there's ample precedent for their use in such a manner, unittest's skip
> decorators, our own decorators for swapping settings during testing, etc.
> Alex
>
> --
> "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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: What is Django?

[Justin Holmes]

Mikhail, et. al.,

I also love the vibe of the django community.  I did not mean, when
writing that line, to put down other communities; I was glad when I
found Django to be greeted by language that did not put down other
frameworks or their philosophies.   Nevertheless, I think that the
language in question is an empirically testable and true statement.
The inverse is also true: Some frameworks, for some use cases, have
distinct and measurable advantages over Django.

I'm not defending the language as it's written - by all means let's
change it.  However, I do think that it's worth mentioning, somehow,
that Django excels in certain areas and that those areas are largely
the result of sensible underlying philosophies.  I think that this
point answers a front-running question in the mind of project managers
who are considering framework adoption.






On Thu, Aug 25, 2011 at 6:30 PM, Julien Phalip <jpha...@yahoo.fr> wrote:
> On 26 August 2011 07:55, Amirouche Boubekki <amirouche.boube...@gmail.com>
> wrote:
>>
>> 2011/8/25 Mikhail Korobov <kmik...@googlemail.com>
>>
>>>
>>> There are many big and well-known sites built with django and I think
>>> mentioning these sites and providing testimonials from people working on
>>> these sites can be better advertisement.
>>
>> Yes and no. Advertising on big websites & applications powered by django
>> would be a plus but it can be misleading. I think anybody could agree that
>> this same applications could have been done in PHP or Flask with the same
>> success (see Facebook ?).
>
> While there are successful and large websites out there built with any
> technology under the sun, I believe it is important to show that you *can*
> use Django to build such sites. Nobody will trust that you are
> webscale™ until you can show some concrete evidence of it :-)
> Seeing that there are successful and large websites built with Django
> certainly isn't enough to convince someone but it isn't just a plus either.
> It is rather the *bare minimum* one needs to be reassured that they're not
> wasting their time learning this new framework.
>
>>
>> Engineers and people that take decisions in general want to know if it
>> gets things done, but also how does it compare to other solutions.
>> Comparing on features would be more engineer-minded that «How do you feel
>> about Django». Engineering is not about feelings, it's a complex choice that
>> weights pros & cons which can be technical but also social and commercial...
>>
>> In javascript world is common to compare frameworks based on speed, size,
>> we could extend this to common problems regarding website building like
>> cache management, authentication, authorization, L10N, I18N, db support,
>> professional support, community support and the like... and even do code to
>> code comparison if it makes sens.
>
> Comparisons are important but I'd rather encourage third parties to write
> them up. Comparisons can really only be trusted from people who have
> extended experience in all the compared frameworks and who do not appear
> biased towards one or another. One should always be cautious with
> websites/frameworks/products/whatever boasting that they are so much more
> awesome than the others :-)
> Julien
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: What is Django?

[Justin Holmes]

Sorry, here's the appropriate link:

https://docs.google.com/document/pub?id=15iJXXKs989cIIvhToa7ttYgToPSyzJN9KL9CCkxka1o

On Thu, Aug 25, 2011 at 2:50 PM, Justin Holmes <jus...@justinholmes.com> wrote:
> I've put some language down to get us started:
>
> https://docs.google.com/document/d/15iJXXKs989cIIvhToa7ttYgToPSyzJN9KL9CCkxka1o/edit?pli=1=en_US
>
>
>
> On Wed, Aug 24, 2011 at 6:31 AM, Cal Leeming [Simplicity Media Ltd]
> <cal.leem...@simplicitymedialtd.co.uk> wrote:
>>
>>
>> On Wed, Aug 24, 2011 at 11:04 AM, Tom Evans <tevans...@googlemail.com>
>> wrote:I'll
>>>
>>> On Tue, Aug 23, 2011 at 6:34 PM, Cal Leeming [Simplicity Media Ltd]
>>> <cal.leem...@simplicitymedialtd.co.uk> wrote:
>>> >
>>> > +1 on this idea :)
>>>
>>> I don't think Russell is looking for votes on whether to do it, he's
>>> looking for someone to actually do it :)
>>
>> Lol, yeah I guessed that already. *adds into todo list*
>>
>>>
>>> Cheers
>>>
>>> Tom
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-developers+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
>
> --
> Justin Holmes
>
> Head Instructor, SlashRoot Collective
> SlashRoot: Coffee House and Tech Dojo
> 60 Main Street
> New Paltz, NY 12561
> 845.633.8330
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: What is Django?

[Justin Holmes]

I've put some language down to get us started:

https://docs.google.com/document/d/15iJXXKs989cIIvhToa7ttYgToPSyzJN9KL9CCkxka1o/edit?pli=1=en_US



On Wed, Aug 24, 2011 at 6:31 AM, Cal Leeming [Simplicity Media Ltd]
<cal.leem...@simplicitymedialtd.co.uk> wrote:
>
>
> On Wed, Aug 24, 2011 at 11:04 AM, Tom Evans <tevans...@googlemail.com>
> wrote:I'll
>>
>> On Tue, Aug 23, 2011 at 6:34 PM, Cal Leeming [Simplicity Media Ltd]
>> <cal.leem...@simplicitymedialtd.co.uk> wrote:
>> >
>> > +1 on this idea :)
>>
>> I don't think Russell is looking for votes on whether to do it, he's
>> looking for someone to actually do it :)
>
> Lol, yeah I guessed that already. *adds into todo list*
>
>>
>> Cheers
>>
>> Tom
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Logging all/slow queries

[Justin Holmes]

Sometimes I feel like the tool I really need is a "stupid query log."

There are times when the ORM produces SQL that is not what I expect,
and I often don't realize this until I go and look at the slow query
log, which is usually after the project is already in some stage of
production or at least staging.

Thus, I do think there is some room for a simple performance tool to
help with this situation, although Alex's point that performance
logging is an industry unto itself it sound.  Is there a well-defined
bite that can be chewed?

On Tue, Jul 19, 2011 at 1:44 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>
>
> On Tue, Jul 19, 2011 at 10:38 AM, Javier Guerra Giraldez
> <jav...@guerrag.com> wrote:
>>
>> On Tue, Jul 19, 2011 at 12:16 PM, David <djfis...@gmail.com> wrote:
>> > This does duplicate
>> > some functionality of RDBMSs but aggregating queries across multiple
>> > databases is really convenient rather than having to go to each
>> > database's logs.
>>
>> i'd also like something like that to have better context.  for
>> example, there are some views that have to finish quickly, and others
>> that could take longer.  the database logs don't discriminate between
>> those, so it's not easy to see which queries are more important to
>> optimize.
>>
>> and of course, it's not always easy to know which ORM produced which
>> SQL.  knowing which Python code produced each SQL means a lot less
>> guesswork.
>>
>> --
>> Javier
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> I'm fairly -1 on anything like this.  Performance logging is an incredibly
> complex task, there are entire companies built around doing it (/waves to
> our friends at New Relic), anything we try to ship in Django itself will a)
> be wrong for many users, and b) woefully inadequate for many more.
> Alex
>
> --
> "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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Old Django Versions

[Justin Holmes]

This question is better suited for the Django-users group:

http://groups.google.com/group/django-users


On Mon, Jun 27, 2011 at 11:54 AM, spencer cole <spencer.c...@gmail.com> wrote:
> Howdy. I'm a new developer for Django. My work is starting work using
> Django 1.3, and I find I really like it as far as I've used it so far.
> My web hosting service, Site5, supports Django, but it's an old
> version(1.1). Is there going to be any issue with what I learn and use
> in Django 1.3 when I try to make my website on my host's servers? Or
> should I install a local version? Also, Site5 runs Python 2.4, should
> I run a local version of 2.7 as well?
>
> Thanks for nay help!
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Javascript Testing

[Justin Holmes]

A javascript testing framework is most desirable.  Thanks for your
work so far - what can we do?

On Sat, Jun 18, 2011 at 8:15 PM, Julien Phalip <jpha...@gmail.com> wrote:
> Hi Sean,
>
> On Jun 18, 4:24 am, Sean Bleier <seble...@gmail.com> wrote:
>> Hello everyone,
>>
>> A couple months ago I started work on a django branch [1] (with the help of
>> @jezdez) that introduces a framework for writing javascript unit tests using
>> QUnit[2].  I started with QUnit because Django already included jQuery in
>> the admin and seemed like a natural extension, but it would be nice to hear
>> opinions from people that know more about javascript testing than I.
>>
>> Since I haven't touch it in a couple months, I thought I would share it with
>> django-developers to get some more eyes on it and discuss any missing
>> features or implementation details. It also be nice if Idan or any other
>> designery person could look it over and give some UI/UX advice.
>>
>> Just to give a overview, the javascript testing framework is initiated by
>> first collecting static media and then starting a special runserver:
>>
>>     ./manage.py collectstatic
>>     ./manage.py jstest
>>
>> This starts a runserver that collects and serves everything you need to run
>> the javascript tests found within an installed app. More detail can be found
>> in these preliminary docs[3], though they need to be moved into their proper
>> place within the docs directory.
>>
>> I'm hoping we can figure out a way forward so that we can start writing
>> tests for the admin and elsewhere.
>>
>> Cheers,
>>
>> --Sean
>>
>> [1]https://github.com/sebleier/django/tree/qunit
>> [2]http://docs.jquery.com/Qunit
>> [3]https://github.com/sebleier/django/blob/qunit/django/test/javascript/...
>
> Thanks a lot for working on this. Django is in dire need of a solid
> javascript test framework.
>
> I've actually been looking at this branch a few weeks ago and it's
> looking very promising! I had a few remarks and questions.
>
> Do you have any specific plans for testing the admin *interface*? My
> main concern is that to properly test complex interactions (e.g.
> dynamically adding or removing admin inlines), you would need to have
> a DOM based on the up-to-date admin templates and on some test data.
> Is it envisaged to plug the QUnit test platform in with a running
> instance of Django that would supply admin pages on the fly, or
> perhaps to introduce a management command that would generate HTML
> files using the up-to-date admin codebase?
>
> Also, one curse of javascript is that it doesn't always behave quite
> the same on all browsers. It would be absolutely awesome if the
> process of testing on multiple platforms and browsers could be
> automated in a CI environment. The Mozilla guys have done some work in
> that area: https://github.com/kumar303/jstestnet -- I haven't tried it
> myself yet. Do you think this could be looked into for Django itself?
>
> Then, as currently in your branch, QUnit tests are expected to be put
> in a "tests/javascript/" folder. Does it mean that the same folder
> structure can be used to run other types of JS test runners? If not,
> would it be best to use a more explicit structure and require that
> tests be put in, for example, "tests/qunit/", in order to leave the
> room for other JS test runners to be supported in the future?
>
> Finally, a ticket has recently been created in Trac for this:
> https://code.djangoproject.com/ticket/16193 -- 'mbraak' posted a patch
> with a few simple tests for the admin JS. It'd be great to see how
> both your works integrate.
>
> Thanks again, this is awesome!
>
> Julien
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: get_object_or_404 hook

[Justin Holmes]

For every convenience method, there are always ways to make it even more
convenient.

I think that if the needs are other than the very most typical use case (ie,
get_object_or_404) than a try block is indicated.

On Thu, Jun 2, 2011 at 10:31 PM, waylybaye <havel...@gmail.com> wrote:

> Hi guys, how about add a hook to get_object_or_404 to render a
> template with  the same name of model when object does not exist ?
>
> For example:
> user = get_object_or_404(User, pk=pk)
>
> if the user does not exist, get_object_or_404 will try to render "404/
> user.html" to show the error page other than a single 404 page for all
> queries.
> It's very useful I think.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Justin Holmes

Head Instructor, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330

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

Re: Proposal: Add current_app to request and pass it to template loaders.

[Justin Holmes]

By "current app," do you mean the app which contains the view to which
the current URL is mapped?

On Mon, Mar 28, 2011 at 12:39 AM, Tai Lee  wrote:
> Now that 1.3 is out, does any core dev have an opinion, feedback or
> suggestions on this?
>
> I've solved my immediate need with two template loaders (subclasses of
> the app_directories loader) that use thread locals. One prefixes the
> requested template name with the app name and the other prefixes it
> with the namespace.
>
> But I'd still like to see Django improved so that users can create
> template loaders which have access to the current app. It would also
> be nice for process_view middleware to have access to the other
> attributes of the ResolverMatch object (app name, namespace, etc) to
> avoid having to resolve URLs twice.
>
> Cheers.
> Tai.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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