Re: Changing the role of the Technical Board

[Eric Matthes]

I want to offer a perspective from outside the Django community.

> I also saw the relative lack of candidates for Board elections and 
essentially thought "better burnt-out me than literally nobody".

I appreciate Andrew's honesty here. I have been a volunteer on our local 
mountain rescue team for about 20 years. That has involved ongoing work 
with our local fire department, which includes EMS and dive rescue 
divisions as well. It also involves work with rescue teams from around 
Alaska, the US, and the rest of the world.

On our local team, many of us have been feeling badly because our numbers 
are down. People have left the team in recent years, and we have had a 
really hard time finding new members. We all start to think we're not doing 
enough, and not doing our work well enough. But when we start to talk to 
each other, we find that this is a widespread issue. Volunteerism is down 
all over the place: in all of the divisions of our department, in various 
regions of our state, and across the country. I'm less clear on how things 
are playing out outside the US. We are having ongoing discussions on how to 
maintain an effective rescue team with all of this in mind. It's not as 
simple as "offer better training", "have more social events", or "implement 
a recruiting drive". We are working towards reframing our team not based on 
the capacities that volunteers had 25 years ago when the team was forming, 
but based on the capacities that people have in our community today.

I don't claim to know if this relates to what we're seeing with the two 
Django boards. But I and others have wanted to step back from our mountain 
rescue leadership positions, and we find ourselves staying in these roles 
for exactly the reason Andrew mentioned here: there's no one ready to 
replace us.

I think the discussions here are moving in the right direction. We are 
looking at the community we have, and figuring out how to build and 
maintain an active leadership group based on the current capacities of our 
community members.

Eric Matthes




On Tuesday, October 25, 2022 at 7:31:14 AM UTC-8 Andrew Godwin wrote:

>
>
> On Tue, Oct 25, 2022, at 12:12 AM, James Bennett wrote:
>
>
> My first reaction to this is: if having a DEP that says the Technical 
> Board is supposed to take the lead in gathering feature proposals didn't 
> get them to do it, it doesn't feel like another DEP saying they're 
> responsible for that is going to fix it.
>
>
> I agree. Me proposing the DEP changes is mostly merely formalising some 
> other changes I want to catalyse here - the DEP is an outcome, not the 
> start, here.
>
> Getting burned out or overcommitted is a thing that happens, and a thing 
> that was anticipated in drafting the governance -- DEP 10 has a procedure 
> for it!
>
> Why did no member of the Technical Board do that?
>
>
> Again, speaking for myself - because we were doing almost all the 
> functions of the Board except for the feature canvassing. I also saw the 
> relative lack of candidates for Board elections and essentially thought 
> "better burnt-out me than literally nobody".
>
> And from the sound of what you're saying in this thread, the Technical 
> Board is mostly communicating with itself about this, in private, when the 
> direction of Django is supposed to be worked out publicly and 
> transparently. That's why we shut down the old private communication spaces 
> for the former "core team" after DEP 10 was adopted.
>
>
> That is not the case - this thread is the majority of the discussion. I 
> opened a thread on the TB mailing list in case people there wanted to give 
> specific, blunt feedback about how they would feel about being affected by 
> this as current Board members, but it has only a couple of replies, and 
> nothing that hasn't been discussed here.
>
> So forgive me for being blunt, but: if the Technical Board is not 
> following the governance we have, I think replacing the Technical Board's 
> current membership should be higher on the list of remedies than replacing 
> the governance.
>
>
> Forgive me for being blunt but... that seems like a really bad idea? The 
> current board ran uncontested, so if all five of us step down I suspect 
> there may not *be* a Board at the end of the day. The DSF Board's current 
> difficulties finding candidates I think reinforces that fact - one of the 
> changes I was considering bringing in here was "what if we have to reduce 
> the TB to 4 or 3 people in the near future".
>
> Again, I'm not saying "we should write a new DEP and *that'll* fix it", 
> I'm trying to come from a position of working out what w

Re: Developer wanted

[Eric 247ERICPOINTCOM]

Hi, Contact me. I am an experienced Django developer, if you still need a
developer.
Thank you

*Kind Regards*

*Eric Bawakuno | Computer Engineer **| 247ERICPOINTCOM |
247ericpointcom.site** | +27795639700 | +27 815152254 | eric...@gmail.com
  | **29 Rochester Road, Observatory | Cape Town, South
Africa | 7925 *



On Sun, Sep 5, 2021 at 11:51 PM 'la...@larrylobert.com' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> I would like to connect with an experienced Django developer to continue
> with some work that was started and nearly completed and to take the
> project to new levels.  Any advice or help in finding someone is
> appreciated.
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8ee7485e-b41b-4e80-8542-f18199e9e495n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/8ee7485e-b41b-4e80-8542-f18199e9e495n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFgqToXMgr3peBWqKypp3S%3DxRAGFqk09k07NEpW4N9v0tQN32g%40mail.gmail.com.

Re: django-formtools is neglected/unmaintained

[eric . verner]

Thanks so much, Tim. I really appreciate it.

On Saturday, January 7, 2017 at 2:05:53 PM UTC-7, Tim Graham wrote:
>
> django-formtools 2.0 is now available on PyPI.
>
> On Thursday, January 5, 2017 at 5:29:43 AM UTC-5, Romain Garrigues wrote:
>>
>> Hi guys,
>>
>> I'm currently investing some efforts to clean and make some django 
>> packages up-to-date.
>> After django-dirtyfields (https://github.com/romgar/django-dirtyfields), 
>> I'm now beginning to work on django-model-utils (
>> https://github.com/carljm/django-model-utils) where there is some work 
>> to update it, but after this, and if nobody else had enough time to have a 
>> look, I can try to contribute on django-formtools.
>>
>> Romain.
>>
>> Le mercredi 4 janvier 2017 23:20:40 UTC, eric@datalyticsolutions.com 
>> a écrit :
>>>
>>> Thanks a lot, Tim! If you think I could help, then let me know. 
>>> Otherwise, I'll just stay out of your way :)
>>>
>>> On Wednesday, January 4, 2017 at 4:02:29 PM UTC-7, Tim Graham wrote:
>>>>
>>>> According to https://github.com/django/django-formtools/issues/75, 
>>>> there's a change in master that's needed for 1.10 compatibility.
>>>>
>>>> I'll try to do a release if I can get access to the PyPI record. I 
>>>> pinged the owner (jezdez) in #django-dev about it.
>>>>
>>>> On Wednesday, January 4, 2017 at 5:51:56 PM UTC-5, Adam Johnson wrote:
>>>>>
>>>>> 1) Tim added testing on Django 1.10 in July 2016, it seems to work? 
>>>>> https://github.com/django/django-formtools/commits/master
>>>>> 2) New contributors are always welcome
>>>>> 3) I don't know of other packages, you can check 
>>>>> https://djangopackages.org/
>>>>> 4) It's true that many websites are built with pure JS frontends these 
>>>>> days, there are probably more recently developed tools there
>>>>>
>>>>> On 4 January 2017 at 22:42,  wrote:
>>>>>
>>>>>> Hi Tim,
>>>>>>
>>>>>> You make some good points. Basically, my situation is that I want to 
>>>>>> use some features of Django v1.10 for a project at my company, but I am 
>>>>>> unable to because I use django-formtools for a FormPreview, and it is 
>>>>>> not 
>>>>>> compatible with v.1.10. I am also worried about using Django for future 
>>>>>> projects given that there seem to be problems finding people to 
>>>>>> contribute 
>>>>>> to what seems to be an important package. Whether I contribute depends 
>>>>>> on 
>>>>>> the answers to several questions: (1) How much work is necessary to get 
>>>>>> formtools compatible with v1.10? (2) Would my contribution make a 
>>>>>> difference, given that I would be a new contributor, and I don't have a 
>>>>>> ton 
>>>>>> of time to give? (3) Is there another package that people are using for 
>>>>>> FormPreviews that I'm not aware of? I couldn't find anything else that 
>>>>>> was 
>>>>>> more up-to-date than django-formtools. (4) Is this a sign that people 
>>>>>> simply aren't using Django for this task, and are maybe instead using 
>>>>>> some 
>>>>>> kind of Javascript library instead? If you have any information these 
>>>>>> questions, please let me know.
>>>>>>
>>>>>> Thanks,
>>>>>> Eric
>>>>>>
>>>>>> On Tuesday, January 3, 2017 at 6:04:59 PM UTC-7, Tim Graham wrote:
>>>>>>>
>>>>>>> Is the situation bad enough that you would volunteer to maintain the 
>>>>>>> project?
>>>>>>>
>>>>>>> The Django team is a collection of volunteers (excepting me) who 
>>>>>>> work on Django. It seems that no one on the team or reading this 
>>>>>>> mailing 
>>>>>>> list has time or interest in maintaining the project. We need to 
>>>>>>> clarify 
>>>>>>> the maintenance status, but that doesn't necessarily mean continuing 
>>>>>>> the 
>>>>>>> project in its current form if there's little interest.
>>>>>>>
>>>>

Re: django-formtools is neglected/unmaintained

[eric . verner]

Thanks a lot, Tim! If you think I could help, then let me know. Otherwise, 
I'll just stay out of your way :)

On Wednesday, January 4, 2017 at 4:02:29 PM UTC-7, Tim Graham wrote:
>
> According to https://github.com/django/django-formtools/issues/75, 
> there's a change in master that's needed for 1.10 compatibility.
>
> I'll try to do a release if I can get access to the PyPI record. I pinged 
> the owner (jezdez) in #django-dev about it.
>
> On Wednesday, January 4, 2017 at 5:51:56 PM UTC-5, Adam Johnson wrote:
>>
>> 1) Tim added testing on Django 1.10 in July 2016, it seems to work? 
>> https://github.com/django/django-formtools/commits/master
>> 2) New contributors are always welcome
>> 3) I don't know of other packages, you can check 
>> https://djangopackages.org/
>> 4) It's true that many websites are built with pure JS frontends these 
>> days, there are probably more recently developed tools there
>>
>> On 4 January 2017 at 22:42,  wrote:
>>
>>> Hi Tim,
>>>
>>> You make some good points. Basically, my situation is that I want to use 
>>> some features of Django v1.10 for a project at my company, but I am unable 
>>> to because I use django-formtools for a FormPreview, and it is not 
>>> compatible with v.1.10. I am also worried about using Django for future 
>>> projects given that there seem to be problems finding people to contribute 
>>> to what seems to be an important package. Whether I contribute depends on 
>>> the answers to several questions: (1) How much work is necessary to get 
>>> formtools compatible with v1.10? (2) Would my contribution make a 
>>> difference, given that I would be a new contributor, and I don't have a ton 
>>> of time to give? (3) Is there another package that people are using for 
>>> FormPreviews that I'm not aware of? I couldn't find anything else that was 
>>> more up-to-date than django-formtools. (4) Is this a sign that people 
>>> simply aren't using Django for this task, and are maybe instead using some 
>>> kind of Javascript library instead? If you have any information these 
>>> questions, please let me know.
>>>
>>> Thanks,
>>> Eric
>>>
>>> On Tuesday, January 3, 2017 at 6:04:59 PM UTC-7, Tim Graham wrote:
>>>>
>>>> Is the situation bad enough that you would volunteer to maintain the 
>>>> project?
>>>>
>>>> The Django team is a collection of volunteers (excepting me) who work 
>>>> on Django. It seems that no one on the team or reading this mailing list 
>>>> has time or interest in maintaining the project. We need to clarify the 
>>>> maintenance status, but that doesn't necessarily mean continuing the 
>>>> project in its current form if there's little interest.
>>>>
>>>> Absent volunteers, another idea could be for an interested freelancer 
>>>> to start a kickstarter-style fundraiser to raise money to fund some time 
>>>> to 
>>>> work on some issue in the backlog. At least it would help determine if any 
>>>> users think the project is worth paying for.
>>>>
>>>> On Tuesday, January 3, 2017 at 7:28:59 PM UTC-5, 
>>>> eric@datalyticsolutions.com wrote:
>>>>>
>>>>> This is really bad. django-formtools used to be part of the core of 
>>>>> Django. Is this getting the attention it deserves from the Django 
>>>>> Foundation?
>>>>>
>>>>> On Monday, November 28, 2016 at 9:55:48 PM UTC-7, Asif Saifuddin wrote:
>>>>>>
>>>>>> Hi Tim,
>>>>>>
>>>>>> In case there is lack of active maintainers for the project then you 
>>>>>> could add me to the list of maintainers. I do contribute to django eco 
>>>>>> system regularly.
>>>>>>
>>>>>> my github activities:
>>>>>>
>>>>>> github.com/auvipy
>>>>>>
>>>>>>
>>>>>> And about moving to jazzband, I do take part in django-admin2 
>>>>>> maintenance there with the two other old maintainers, The fact is moving 
>>>>>> it 
>>>>>> to jazzband haven't increased the active co maintainers.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Asif
>>>>>>
>>>>>> On Tuesday, November 29, 2016 at 5:45:5

Re: django-formtools is neglected/unmaintained

[eric . verner]

Hi Tim,

You make some good points. Basically, my situation is that I want to use 
some features of Django v1.10 for a project at my company, but I am unable 
to because I use django-formtools for a FormPreview, and it is not 
compatible with v.1.10. I am also worried about using Django for future 
projects given that there seem to be problems finding people to contribute 
to what seems to be an important package. Whether I contribute depends on 
the answers to several questions: (1) How much work is necessary to get 
formtools compatible with v1.10? (2) Would my contribution make a 
difference, given that I would be a new contributor, and I don't have a ton 
of time to give? (3) Is there another package that people are using for 
FormPreviews that I'm not aware of? I couldn't find anything else that was 
more up-to-date than django-formtools. (4) Is this a sign that people 
simply aren't using Django for this task, and are maybe instead using some 
kind of Javascript library instead? If you have any information these 
questions, please let me know.

Thanks,
Eric

On Tuesday, January 3, 2017 at 6:04:59 PM UTC-7, Tim Graham wrote:
>
> Is the situation bad enough that you would volunteer to maintain the 
> project?
>
> The Django team is a collection of volunteers (excepting me) who work on 
> Django. It seems that no one on the team or reading this mailing list has 
> time or interest in maintaining the project. We need to clarify the 
> maintenance status, but that doesn't necessarily mean continuing the 
> project in its current form if there's little interest.
>
> Absent volunteers, another idea could be for an interested freelancer to 
> start a kickstarter-style fundraiser to raise money to fund some time to 
> work on some issue in the backlog. At least it would help determine if any 
> users think the project is worth paying for.
>
> On Tuesday, January 3, 2017 at 7:28:59 PM UTC-5, 
> eric@datalyticsolutions.com wrote:
>>
>> This is really bad. django-formtools used to be part of the core of 
>> Django. Is this getting the attention it deserves from the Django 
>> Foundation?
>>
>> On Monday, November 28, 2016 at 9:55:48 PM UTC-7, Asif Saifuddin wrote:
>>>
>>> Hi Tim,
>>>
>>> In case there is lack of active maintainers for the project then you 
>>> could add me to the list of maintainers. I do contribute to django eco 
>>> system regularly.
>>>
>>> my github activities:
>>>
>>> github.com/auvipy
>>>
>>>
>>> And about moving to jazzband, I do take part in django-admin2 
>>> maintenance there with the two other old maintainers, The fact is moving it 
>>> to jazzband haven't increased the active co maintainers.
>>>
>>> Thanks,
>>>
>>> Asif
>>>
>>> On Tuesday, November 29, 2016 at 5:45:59 AM UTC+6, Tim Graham wrote:
>>>>
>>>> Hi,
>>>>
>>>> django-formtools seems neglected. It's been several months since the 
>>>> release of Django 1.10 but a compatible version of formtools hasn't been 
>>>> released to PyPI.
>>>>
>>>> Personally, I don't know if it's important to maintain it as an 
>>>> "official project." An alternative could be to "donate" it to JazzBand (
>>>> https://jazzband.co/) and see if the community maintains it.
>>>>
>>>> If you have an interest in this package (especially if you want to 
>>>> maintain it), let us know.
>>>>
>>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5e728ee6-f722-4286-ade5-facfb81d3899%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-formtools is neglected/unmaintained

[eric . verner]

This is really bad. django-formtools used to be part of the core of Django. 
Is this getting the attention it deserves from the Django Foundation?

On Monday, November 28, 2016 at 9:55:48 PM UTC-7, Asif Saifuddin wrote:
>
> Hi Tim,
>
> In case there is lack of active maintainers for the project then you could 
> add me to the list of maintainers. I do contribute to django eco system 
> regularly.
>
> my github activities:
>
> github.com/auvipy
>
>
> And about moving to jazzband, I do take part in django-admin2 maintenance 
> there with the two other old maintainers, The fact is moving it to jazzband 
> haven't increased the active co maintainers.
>
> Thanks,
>
> Asif
>
> On Tuesday, November 29, 2016 at 5:45:59 AM UTC+6, Tim Graham wrote:
>>
>> Hi,
>>
>> django-formtools seems neglected. It's been several months since the 
>> release of Django 1.10 but a compatible version of formtools hasn't been 
>> released to PyPI.
>>
>> Personally, I don't know if it's important to maintain it as an "official 
>> project." An alternative could be to "donate" it to JazzBand (
>> https://jazzband.co/) and see if the community maintains it.
>>
>> If you have an interest in this package (especially if you want to 
>> maintain it), let us know.
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4ffc5fa7-9664-4f03-8550-7dc32f45374a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

[Eric Holscher]

Happy to help with this. We can move the RTD builds to using Sphinx 
HTMLDir, and then redirects won't be necessary for the page titles, at 
least. 

On Thursday, February 18, 2016 at 12:58:03 PM UTC-4, Florian Apolloner 
wrote:
>
>
>
> On Thursday, February 18, 2016 at 4:24:09 PM UTC+1, Tim Graham wrote:
>>
>> I guess I'm not strongly opposed if someone wants to do that, but I don't 
>> think I can justify spending time on the DSF's dime to help out users of 
>> unsupported versions.
>>
>
> +1
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cf9fed8a-e41c-4f99-9326-2f17c0a18827%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

   
   1. it's not necessarily about SSL, it can be for any protocol but SITE 
   dependent.
   2. and for the dev/prod , your data will be different anyway so you put 
   the preferred protocol accordingly to your setup.
   3. it's only for generating full URLs, not for internal links (ex: 
   sitemaps). 

a settings option could work too for sure, but I think we have more 
flexibility with the sites framework, and any time you need the protocol 
it's to generate a full URL which also needs the domain name.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2d0a6998-e21d-4a56-8380-2cf1273e3f97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

since no feedback has been given yet,   I will add that the change is just 
an addition (new feature)  meaning there is no breaking of code , it just 
provides a way to define a default protocol for a given SITE, and will 
ultimately default to http when none is specified

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df5ea735-b41e-4197-96a8-2cb6333bf3de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

Hi

I've created a ticket to propose adding a preferred/default protocol in the 
"sites" framework at https://code.djangoproject.com/ticket/26079

tim suggested I bring this to the mailing list and said the following:

I'm not immediately convinced that a database field is the way to go for a 
> couple reasons:
>
>1. It would make data less portable between development (where SSL is 
>often not in use) and production.
>2. I'm not sure it's a common case that only some sites would use SSL 
>but not others.
>
> A third-party library called django-hosts, which djangoproject.com uses, 
> adds a setting called ​HOSTS_SCHEME 
> 
>  to 
> solve this. I think there's been some discussion about merging at least 
> parts of this library into core since it solves common problems.
>
> See also #10944  (we might 
> close this ticket as a duplicate of that one) and #23829 
>  (about customizing 
> ping_google to allow https). I think the best course of action would be 
> to consider this feedback and write to the DevelopersMailingList 
>  with your 
> proposal. Either solution of a new setting or a new database field need 
> feedback from a wider audience. Thanks!
>

   - actually I would say it is even more portable as you 
   would probably use different databases between dev and prod , meaning you 
   can have http in dev but https in prod
   - its not just for SSL but also maybe a it could be used with other 
   protocols/schemes such as dav, webcal, feed
   - third party libraries could now have a definitive way of generating a 
   full URL 

what do you guys think?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4daa6fb3-071a-4ca0-849c-63283cc3737b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Eric Holscher]

On Tuesday, December 29, 2015 at 2:17:31 PM UTC-8, Tim Graham wrote:
>
>
> Turning the table of contents page into a CSS menu sounds like a possibly 
> worthwhile task.
>
> There is also an idea here for adding navigation breadcrumbs to the 
> documentation which might help:
> https://github.com/django/djangoproject.com/issues/403
>

Yea, I think the global TOC that the Read the Docs theme has is pretty good 
at surfacing the structure of the 
docs: http://docs.readthedocs.org/en/latest/ -- it allows users to see 
where in the hierarchy they are, and what levels make sense.

That is already what is generating the TOC that is on the contents page, so 
it would be pretty easy to include that in the sidebar for the docs (I 
believe it's the `toc` variable in the Jinja template, but Django is using 
the custom JSON backend, which works differently). I think Django's TOC is 
quite large, so it would be hard to make it fit nicely into the sidebar, 
but having the information available one each page would likely be useful 
for UX. Perhaps you could at least do the top-level items, and an expanded 
view of the current tree (the `collapse` option here 
http://sphinx-doc.org/templating.html#toctree)
 

>
>
> On Tuesday, December 29, 2015 at 4:48:37 PM UTC-5, Tim Allen wrote:
>>
>> Tim: that's definitely a big help, but still a click away. I'm just 
>> brainstorming here, please bear with me!
>>
>> I think part of my confusion as a newbie is from the front page itself, 
>> at https://docs.djangoproject.com/
>>
>> Now that I understand the concepts behind the documentation better 
>> (thanks Daniele), it doesn't appear to be very well reflected on the front 
>> page. There is a list of First steps, The model layer, and so on, but 
>> nothing in the interface that clearly lets the user know that the 
>> documentation is meant to be broken down into the "Tutorials / How-To / 
>> Explanation & Discussion / Reference" paradigm. If that's what we are 
>> trying to communicate, it should be shown to the user from the front of the 
>> documentation clearly, IMHO.
>>
>> A top-down, browsable hierarchy would have been extremely useful to me 
>> when I was just getting started. The ToC has the kind of hierarchy I'm 
>> referring to (https://docs.djangoproject.com/en/1.9/contents/), but 
>> comes across to the user as a wall of text / links. Perhaps developing the 
>> ToC into a navigation menu is worth some effort?
>>
>> Does anyone else feel there is far too much on the front page? An 
>> experienced Django dev will be more comfortable finding what they need 
>> within the documentation, am I alone in thinking a much more simple front 
>> page might be useful to the newcomer?
>>
>> Regards,
>>
>> Tim
>>
>> On Tuesday, December 29, 2015 at 11:25:40 AM UTC-5, Tim Graham wrote:
>>>
>>> I've refined Daniele's explanation here: 
>>> https://github.com/django/django/pull/5888
>>>
>>> Let me know if it helps and what could be better.
>>>
>>> On Monday, December 28, 2015 at 11:31:30 PM UTC-5, Eric Holscher wrote:
>>>>
>>>>
>>>>
>>>> On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote:
>>>>>
>>>>> On Mon, Dec 28, 2015, Samuel Bishop  wrote:
>>>>> The main existing sections are: 
>>>>>
>>>>> * tutorials (/intro) 
>>>>>
>>>>> Tutorials take the new user by the hand through a series of steps. The 
>>>>> important thing isn't to explain all the steps, but to achieve something 
>>>>> useful with a minimum of effort. 
>>>>>
>>>>> After every step of a tutorial, the user should have something that 
>>>>> works, even if they barely understand what is happening (and it's not 
>>>>> necessary for them to understand, that can come later. What matters is 
>>>>> that 
>>>>> they are successful). 
>>>>>
>>>>> * how-to guides (/howto) 
>>>>>
>>>>> How-to guides are recipes that take the user through steps in key 
>>>>> subjects. They are more advanced than tutorials and assume a lot more 
>>>>> about 
>>>>> what the user already knows than tutorials do, and unlike documents in 
>>>>> the 
>>>>> tutorial they can stand alone.   
>>>>>
>>>>> * discussion and explanation (/topic) 
>>>>>
>>>>> Aimed at explaining 

Re: structural & functional review of django documentation

[Eric Holscher]

On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote:
>
> On Mon, Dec 28, 2015, Samuel Bishop > 
> wrote:
> The main existing sections are: 
>
> * tutorials (/intro) 
>
> Tutorials take the new user by the hand through a series of steps. The 
> important thing isn't to explain all the steps, but to achieve something 
> useful with a minimum of effort. 
>
> After every step of a tutorial, the user should have something that works, 
> even if they barely understand what is happening (and it's not necessary 
> for them to understand, that can come later. What matters is that they are 
> successful). 
>
> * how-to guides (/howto) 
>
> How-to guides are recipes that take the user through steps in key 
> subjects. They are more advanced than tutorials and assume a lot more about 
> what the user already knows than tutorials do, and unlike documents in the 
> tutorial they can stand alone.   
>
> * discussion and explanation (/topic) 
>
> Aimed at explaining (at a fairly high level) rather than doing. 
>
> * reference (/ref) 
>
> Technical reference for APIs, key models and so on. It doesn't need to 
> explain so much as describe and instruct. 
>
>  
I think the above post does a good job of describing the layout, and 
something similar should be included in the docs. Without having read 
Jacob's posts on the subject, there is nothing in the official docs that 
gives the reader an understanding that this is how things are laid out, as 
far as I know.

I think the underlying structure makes sense, and it seems that mostly 
people are just upset about the lack of a pure auto-generated code 
reference. I believe historically that this has been excluded explicitly, 
not because of lack of technology. There is no use of autodoc in the Django 
tree, even where it might make sense.

At Django Under the Hood this year, I had a few conversations with folks 
about rethinking and explicitly defining these policies. I think it makes a 
lot of sense to write down the logic and structure behind these decisions 
in a DEP, and explain the layout to doc users in a few places in the 
documentation explicitly.

Cheers,
Eric 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0daa98a8-6714-4f76-adb2-ea5ced43d361%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What are the best reasons for when and why people should use Django?

[Eric Frost]

Django Developers,

I'm giving a talk at a general tech conference next week and it's
mostly ready, but would welcome response for when and why developers
should look to Django (vs. other frameworks like Ruby on Rails) when
starting new projects.

Would love to hear any thoughts and arguments!

Thanks!
Eric
m: 312-399-1586

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

Re: Revisiting multiline tags

[Eric Rouleau]

+1 for me too

On Thursday, March 6, 2014 3:28:59 PM UTC-5, Andre Terra wrote:
>
> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis 
> > wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini 
>> 
>> > wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they 
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail 
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is 
>>> presentational log and belongs in templates (<- unless I'm wrong about 
>>> that, please suggest a refactoring to me if you believe one is appropriate 
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>

 On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:

> My grandfather was a developer in a nuclear plant that I was interning 
> at.  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release 
> of nuclear material.  While building the application, my grandfather put 
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and 
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some 
> reason it never detected that it was safe to release the deadly fissile 
> material (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and 
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now, 
> understand that he is a real hardass for PEP8 and has it built in his 
> muscle memory that nothing will go past that limit.  Unfortunately, my 
> extra statement just happened to go right over the 80 character limit 
> (check it), so he didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of 
> deadly, central nervous system destroying radiation we had built up in 
> the 
> reactor (that stuff tends to clog up the pipes).  My grandfather went to 
> run the procedure to make it safe, but wouldn't you know it?  That debug 
> statement was still there.  Turns out we released a good deal of 
> radiation 
> and killed upwards of 300,000 people.  They had to evacuate the city and 
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off 
> that he has to scroll past the 80 character column to fix the issue.
>
  
 As amusing as your story is, hyperbole won't win the argument.  

 Hyperbole aside, you haven't added anything to the discussion that we 
 didn't already know. Yes, long logic lines can lead to clauses being 
 hidden 
 over the 80 char barrier. This isn't news.

 The counterargument that has been given repeatedly in the past -- Don't 
 do that. One of the reasons that Django's template logic is intentionally 
 hobbled is that we want to discourage putting business logic in the 
 template. Not adding multiline tags is one of the contributors to this 
 hobbling. Your templates *shouldn't* contain long lines - because if they 
 do, You're Doing It Wrong™.

 How should it be done? Depending on circumstances, you could refactor 
 the "is it ok to show the form" logic into:

  * a method on the reactor object:

 {% if reactor.ok_to_show_form %}

  * the view that constructs the context that the template uses:

 {% if ok_to_show_reactor_form %}

  * a template filter

 {% if reactor|ok_to_show_form %}

  * a template tag setting a local value in the context

 {% show_form_state as ok_to_show_form %}
  {% if ok_to_show_form %}

 All of these come in at *much* less than 80 characters, and better 
 still, they all force you to put the "display the form" logic somewhere 
 that it can be tested and validated, so no only will your grandfather be 
 able to read his template unambiguously, but he'll be able to write formal 
 tests to ensure that humanity isn't doomed to a future of extra limbs and 
 superpowers.

 Which one of these approaches is the best for your circumstances will 
 de

`collectstatic --ignore` pattern matching

[Eric Eldredge]

Hi all,

I'm working on a project where I want to ignore certain files when running 
collectstatic.

I am having success only when i use 'basename' patterns, such as *.exe or 
vendor, but not when trying to match file paths, such as vendor/*.exe.

It seems the reason i'm not seeing the behavior i expect is because 
django.contrib.staticfiles.utils.get_files
 only 
checks the ignore patterns on the base names (for both files and 
directories), but does not check the full file path.

Is this the correct behavior, or a bug? If it is the correct behavior, what 
is the recommended approach for gaining more fine-grained control over what 
is collected by collectstatic?

Thanks in advance for any consideration.

-- 
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/90be2650-cf11-4600-922b-f9604248d9a3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Passing extra data to validator

[Eric Cheung]

It's only able to access a field value in validator but it would be lacked 
if checking request object data. 
Should better to have another parameter for passing data to validators? 
Maybe like this:

form = MyForm(request.POST, validator_data={'user': request.user})

def my_validator(value, validator_data):
user = validator_data.get('user')
# check something 

-- 
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: Database pooling vs. persistent connections

[Eric Florenzano]

One question: does this proposal include some way of specifying a maxiumum 
number of outstanding connections to the database from a single process? 
 Looked but didn't see it in the pull request.  In my experience, most 
PostgreSQL instances don't have a whole lot of breathing room in terms of 
the number of total outstanding connections they can handle due to low 
shared memory defaults etc. This is something that django-postgrespool does 
by way of SQLAlchemy's pool_size and max_overflow settings.

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

Re: Custom user models don't like non integer primary keys.

[Eric Hutchinson]

Sorry for disappearing there.

I didn't think a full trace was necessary, russ nailed that particular 
instance. As a user of django, I don't think for 1.5 that you need to 
change the behavior of views. It just blind sided me that the custom auth 
model needed an integer ID and it should be added to the docs before 
release. 

It'd be super nice if it worked with other field types, but I don't see it 
being a big deal if it's documented as being that way.

On Tuesday, November 6, 2012 6:07:14 PM UTC-5, Russell Keith-Magee wrote:
>
> Hi Eric,
>
> Although the full stack trace would confirm it, I think I can guess what 
> the problem is here -- it's the mechanism for generating reset tokens. 
>
> If you dig into the token generation (and reversal) mechanisms, they use 
> int_to_base36 and base36_to_int to convert the user's primary key into 
> something that can be used as a reversible, text-based identifier of the 
> user object that isn't the literal identifier itself. This identifier is 
> then used as part of the password reset token (along with a timestamp 
> component and a component based on the last login timestamp)
>
> A base36 encoding of an integer produces a nice reversible alphanumeric 
> representation of the integer primary key that can be used in this reset 
> token. 
>
> So, yes -- non-integer primary keys will have a problem with any of the 
> password reset or account activation logic. These should (he says, 
> hopefully) be the only views that are affected.
>
> One of the big features for Django 1.5 is the introduction of swappable 
> user models. However, even with that change, we've maintained the 
> requirement that the User model has an integer primary key
>
> That said, I'm not personally opposed to dropping this requirement -- we 
> just need to find a way to abstract the PK-dependent tokenization part in a 
> useful way. As an initial thought, this is something that we could abstract 
> out to the token generator API; the token generator is already customisable 
> in the password reset views. However, I'm certainly open to other 
> approaches.
>
> Yours,
> Russ Magee %-)
>
> On Wed, Nov 7, 2012 at 3:19 AM, Jacob Kaplan-Moss 
> 
> > wrote:
>
>> Hey Eric --
>>
>> Can you post the full traceback instead of just the snippet? Without
>> that it's not clear whether this is a bug or just a consequence of
>> defining your own custom user model. As the documentation notes:
>>
>> """
>>
>> As you may expect, built-in Django's forms and views make certain
>> assumptions about the user model that they are working with.
>>
>> If your user model doesn't follow the same assumptions, it may be
>> necessary to define a replacement form, and pass that form in as part
>> of the configuration of the auth views.
>> """
>>
>> So it might be the case that you just need to be customizing more
>> stuff to deal with your special model. Or not, but we probably need
>> more info to decide either way.
>>
>> Jacob
>> Jacob
>>
>>
>> On Tue, Nov 6, 2012 at 12:43 PM, Eric Hutchinson
>> > wrote:
>> > I've been playing with custom user models. Something i've found is that
>> > trying to use the django-extensions uuidfield as a primary key doesn't 
>> seem
>> > very usable at the moment.
>> >
>> > Many of the built in auth views, specifically password reset, assume an
>> > integer field here.
>> >
>> > /lib/python2.7/site-packages/django/utils/http.py", line 187, in
>> > int_to_base36
>> > raise TypeError("Non-integer base36 conversion input.")
>> > TypeError: Non-integer base36 conversion input.
>> >
>> >
>> > Also, in the admin when creating a new user with the example admin setup
>> > from the docs, even though it would seem to have no reason to i get it
>> > trying to redirect to /app/model/(integer)/ when the id is clearly a 
>> uuid.
>> >
>> > I know this isn't that helpful, but I don't know if this is just 
>> something
>> > you might want to warn about in the docs, or if this is something you 
>> want
>> > to fix in the built-in auth views, or what.
>> >
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups
>> > "Django developers" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
>> > To post to this group, 

Custom user models don't like non integer primary keys.

[Eric Hutchinson]

I've been playing with custom user models. Something i've found is that 
trying to use the django-extensions uuidfield as a primary key doesn't seem 
very usable at the moment.

Many of the built in auth views, specifically password reset, assume an 
integer field here. 

/lib/python2.7/site-packages/django/utils/http.py", line 187, in 
int_to_base36
raise TypeError("Non-integer base36 conversion input.")
TypeError: Non-integer base36 conversion input.


Also, in the admin when creating a new user with the example admin setup 
from the docs, even though it would seem to have no reason to i get it 
trying to redirect to /app/model/(integer)/ when the id is clearly a uuid.

I know this isn't that helpful, but I don't know if this is just something 
you might want to warn about in the docs, or if this is something you want 
to fix in the built-in auth views, or what.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
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: Call for use cases of metrics in django core

[Eric Holscher]

A couple obvious places:

Latency to backend systems. So, any time that I call out to my cache 
backend or database, keep track of round trip latency of those. 

Full system latency. So, From the time a request enters the URL routing 
until it gets sent back to a client.

Request counts. Keep track of the number of times a specific view or 
urlconf entry has been hit. This might be a bit intensive, and not worth 
having on.

Average latency for every view. So you can keep track of what views are the 
slowest.

Query counts on a per-view and overall system view.

Cache hit rates as viewed by the cache backend.

Error counts on a per-view basis. Also probably for any backend system 
interface. 

These are the first things that came to me. I'm sure some of them are a bit 
heavy weight for what we want to do. There are likely also other places 
where you would want to provide stats.

As for implementation, we've been using mmstats[0] at Urban Airship 
successfully. It does require C bits, so it might not be great for Django, 
especially in regards to pypy integration. However, it is pretty darn low 
overhead, and might be worth at least stealing some ideas from.

0: http://mmstats.readthedocs.org/en/latest/

Cheers,
Eric


On Wednesday, October 31, 2012 3:41:05 PM UTC-7, jdunck wrote:
>
> If you use/monitor/graph metrics (the idea, not Coda's library, but that 
> would be good, too), I'd like to hear from you.  
>
> What sort of metrics, under what implementation, would be useful to you 
> operationally?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/6fJavfHAVNgJ.
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: Optional operator index discussion

[Eric Floehr]

ies (case 
insensitive, multi-column, partial, etc.) and would generate CREATE INDEX 
statements that are specific to the underlying db (or not create if the db 
doesn't support).  This would be functionality not common in ORMs today, 
and Django would be a trail-blazer in this area.


Are there any I'm missing?  What seems like the most viable direction to 
take?

Thanks!
Eric

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/c4pH0-mo1IoJ.
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.

Optional operator index discussion

[Eric Floehr]

I'd like to open up a discussion on the possibilities of having a way to 
optionally specifying not to create operator indexes on CharField's when 
db_index=True.  Based on the consensus from this discussion, I'll open up a 
ticket and if it is within my abilities, generate a patch.

For background, ticket #12234 (https://code.djangoproject.com/ticket/12234) 
resulted in the creation of a second index for all CharField's and 
TextField's when db_index=True to enable LIKE queries to work as they 
should.

However, there are many use cases where a CharField index is needed but 
adding a varchar_pattern_ops index (in PostgreSQL) results in a performance 
and storage space hit.  In my case, The storage space difference was 550GB 
with varchar_pattern_ops indices and 300GB without.  I don't have an exact 
statistic on the drop in insert speed, but it was noticeable.

In my case, these varchar fields are of small width, generally 1 to 4 
characters, and indexing is important on the complete field.  However, it 
will never be the case that LIKE will be used to query for partial matches, 
so LIKE query speed isn't an issue, and an operator index is a 
performance/storage hit that isn't justified.

I am working around the problem now with a custom Field class, but it seems 
to me that this is a feature that others may benefit from and wanted to 
solicit feedback and ideas for if it should be an option, and if so, what 
form it should take.

Thanks much,
Eric

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/NbYgWQVhBYEJ.
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: auth.user refactor: the profile aproach

[Eric Florenzano]

I completely agree with Adrian's proposal, with these amendments suggested 
by Russell in order to build something slightly more generic, like 
LazyForeignKey, instead of UserField.  In fact, a UserField coud end up 
being provided as a subclass of LazyForeignKey with a default name provided 
(e.g. 'user') and any other user-domain-specific customizations needed.

Thanks,
Eric Florenzano

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/h1uVd02e7owJ.
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: jQuery.tmpl() and Django

[Eric Florenzano]

On May 26, 11:59 pm, Jonathan Slenders 
wrote:
> +1 for the verbatim tag. I think this is something that we need in
> Django by default.
>
> But I think that ericflo his implementation is not truly verbatim. I
> mean, that it will probably drop whitespace between "{%" and the tag
> names. It may not be important for jQuery, but if we implement
> verbatim, the output should be an exact copy of the verbatim contents.

This is true.  I couldn't find an easy way to implement a verbatim tag
that was truly "verbatim" at the time without making changes to
Django's internals.

-Eric

-- 
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: NoSQL support

[Eric Florenzano]

On Apr 28, 2:36 am, "Jonas H."  wrote:
> For anyone who's interested, here's the complete diff of Django-nonrel
> against Django 1.3:http://paste.pocoo.org/show/379546/

Are you sure this diff is correct?  From a quick look over that diff,
it seems there's a bunch of seemingly unrelated changes in there
having to do with password resetting, base64 url encoding, and file
uploading--none of which have to do with NoSQL.

Thanks,
Eric Florenzano

-- 
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: Brute force attacks

[Eric Hutchinson]

I would just like to point out that a lot of my users all are behind
various nats, so my webapp typically sees only a few ips that have
valid users on them, and i have users whom i have to remind of their
password on a daily basis. it could lead to a couple of dozen people
being throttled for one person who doesn't know their caps key being
lit up green is why their password isn't working

i'm not saying this is a situation the default should take care of,
but something to keep in mind when designing any backend classes, so
that just the bit that determines the cache key or whatever should be
override-able.

On Mar 7, 1:01 pm, Rohit Sethi  wrote:
> Looks like we're on the same page. I agree that we need something
> lightweight designed to repel brute force from a single IP. Something
> designed to detect distributed attacks would require more overhead and
> monitoring and probably doesn't belong in core. That said, I believe
> we should think about logging error messages using OWASP AppSensor
> detection point codes (http://www.owasp.org/index.php/
> OWASP_AppSensor_Project#tab=Detection_Points) so that a third party
> monitoring tool can detect an attack on the application. Perhaps one
> day we could extend this standardized security logging to
> authorization failures as well.
>
> We balance against DoS by slow incrementing the timeout period. We'll
> certainly need to experiment with this to get sensible values, but I'd
> suggest thinking about doubling the timeout period for every
> successive failed attempt starting from some configurable value such
> as 5 seconds up to some configurable maximum such as 4 hours. Ideally
> throttling wouldn't kick until at least three failed attempts (also
> configurable). To reiterate, all numbers above are just examples -
> we'll need to test in some real world conditions to figure out the
> best default values.
>
> On Mar 6, 7:46 pm, Paul McMillan  wrote:
>
>
>
>
>
>
>
> > I go back and forth on this issue. Unlike CSRF, there's never going to
> > be a one size fits all solution for this type of problem. Different
> > organizations have widely varying requirements, and while I prefer
> > rate limits, that won't satisfy the auditor whose checklist requires
> > permanent lockout after X attempts.
>
> > That said, Django's current approach of "figure something out
> > yourself" means that most installs don't get any work in this realm.
> > We can't defend against every attack scenario, but if we can improve
> > the most common areas, it will be a substantial gain.
>
> > I'm quite interested in working to get better protection into core. I
> > agree with Rohit that throttling/rate-limiting is going to be where
> > Django finds a good balance between intrusiveness and security. In
> > larger systems, this task is often taken care of by the firewall in a
> > generic one-size-fits-all fashion, but if Django is doing the
> > limiting, we can provide more specific protection, especially for
> > users who don't have fine-grained control over their firewall.
>
> > If we build a rate limiter into core, it will encourage users to make
> > use of it in their own projects. It will also allow us to rate limit
> > other areas of core to improve security - passwords are far from the
> > only thing susceptible to brute force, and the same framework may be
> > useful to prevent or discourage DoS.
>
> > We need to be careful to provide permissive defaults. Leave the knobs
> > exposed for organizations which require draconian measures, but for
> > the average user, convenience trumps security.
>
> > At the expense of creating more work, I think that we need to agree on
> > several facets of the problem before we go writing code:
>
> > 1) Which attack scenarios do we protect against?
>
> > A single machine high-rate attack? A high-rate distributed attack? A
> > slow distributed attack?
>
> > The first of these is the most likely attack - it's easy to implement,
> > and doesn't require extensive resources or patience. Defenses against
> > it will also apply (to a lesser extent) in the case of a high-rate
> > distributed attack. Measures like locking accounts after a number of
> > login failures prevent the slow attack, but they inconvenience users
> > and open a very nasty avenue for DoS. I don't know of measures Django
> > could take which would provide an acceptable balance between
> > completely preventing this attack and avoiding inconveniencing users.
>
> > 2) How do we balance protection against DoS concerns?
>
> > Since Django installations are usually public-facing, Denial of
> > Service issues are often a larger concern than brute force attacks
> > (the entire site being unavailable vs. some number of compromised user
> > accounts) I strongly oppose the addition of any code which makes
> > Django significantly more vulnerable to DoS out of the box, even if it
> > does improve security.
>
> > 3) What is the appropriate response to an attacker?
>
> > Lock the account? Deny access to 

Re: r13363 change to use pg_get_serial_sequence

[Eric]

On Dec 23, 2:55 pm, Christophe Pettus  wrote:
> On Dec 23, 2010, at 11:35 AM, Eric wrote:
>
> > a) To fix this, one must identify the sequences that are not correct.
> > I scoured pg_catalog and friends and cannot identify where PostgreSQL
> > exposes the link between the "id" and sequence columns.
>
> Just FYI, it's stored in pg_depend.

Thanks for the tip. If anyone else hits this, the following adapted
from another pg recipe will output all correct id <-> serial
ownerships.

SELECT s1.nspname || '.' || t1.relname AS tablename,
a.attname,
s2.nspname || '.' || t2.relname AS sequencename
FROM pg_depend AS d
JOIN pg_class AS t1 ON t1.oid = d.refobjid
JOIN pg_class AS t2 ON t2.oid = d.objid
JOIN pg_namespace AS s1 ON s1.oid = t1.relnamespace
JOIN pg_namespace AS s2 ON s2.oid = t2.relnamespace
JOIN pg_attribute AS a ON a.attrelid = d.refobjid AND a.attnum =
d.refobjsubid
WHERE t1.relkind = 'r'
AND t2.relkind = 'S'
ORDER BY tablename, a.attname, sequencename;

Comparing the output of a production database vs. what Django would
create natively on an empty DB will spit out the exact columns that
are missing the OWNED BY link. I'm sure there's a more elegant way,
but this was quick and easy.

Thanks Christophe!

>
> --
> -- Christophe Pettus
>    x...@thebuild.com

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

r13363 change to use pg_get_serial_sequence

[Eric]

We recently started the test and upgrade process to bring our large
Django applications more up to date with 1.3 to help test new things.
We found that http://code.djangoproject.com/changeset/13363 introduced
backwards incompatible changes.

Previously, using PostgreSQL, it was possible to take a manually
defined INTEGER column and create a sequence and set the nextval()
just as the SERIAL type does. Prior to 1.3, this worked fine as long
as you named your sequence correctly.

For example, we had a table named nut_food with "id INTEGER NOT NULL
DEFAULT NEXTVAL('nut_food_id_seq'::regclass)" -- so at first glance,
all appeared correct. However, inserting a new record with
"Food.objects.create(..) would *silently* fail and assign None to the
instance in Python, despite the record actually having an ID in the
database.

Two things of note:

a) To fix this, one must identify the sequences that are not correct.
I scoured pg_catalog and friends and cannot identify where PostgreSQL
exposes the link between the "id" and sequence columns. We only
identified the column in error by getting exceptions in the code that
was using .pk. Once the errant columns are found:

ALTER SEQUENCE nut_food_id_seq OWNED BY nut_food.id;

must be run for each sequence/table/column. Without this,
pg_get_serial_sequence('"table_name"', 'column_name") returns NULL.

When Django creates tables or one has tables set up with a true SERIAL
column, the above is not needed. It's *only* when the "serial" is
manually constructed, such as from legacy or external databases.

This may be useful to note in the Release Notes for 1.3 as a backwards
incompatible change.

b) The last_insert_id method in the postgresql backend will silently
fail for any expected sequences and return None.
pg_get_serial_sequence() returns NULL when it cannot find a sequence,
and currval() returns NULL as well when passed NULL.

def last_insert_id(self, cursor, table_name, pk_name):
cursor.execute("SELECT CURRVAL(pg_get_serial_sequence('%s','%s'))"
% (table_name, pk_name))
last_id = cursor.fetchone()[0]
if last_id is None:
raise IntegrityError("Valid sequence not found for %s.%s." %
(table_name, pk_name))
return last_id

would at least make this (and future sequence issues) at least visible
instead of silently failing.

Regards,

Eric

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

Re: Contributing more

[Eric Holscher]

Hey Laurent,

Glad to hear you want to help out!

The first step that I usually take is figuring out what component I want to
work on. This is usually based around what I have the most familiarity with,
or what part I'm interested in learning more about. Trac has nice features
for filtering down by component, so for example I usually work on stuff with
the test framework, so I'd use something like this:

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=component&component=Testing+framework&milestone=1.3&order=priority

Then once you find a ticket that looks interesting, I'd start with the
triage process. The contributing docs are good to read to figure out what
style of patches are good, and what the triage stages look like:

http://docs.djangoproject.com/en/1.2/internals/contributing/#submitting-patches

However, as a quick primer, I'd just look for tickets that are "Accepted",
and if they have a patch, review them. If you think they are ready to go
into trunk (have docs & tests, good style), feel free to mark them as "Ready
For Checkin". This shows a core committer patches that should be checked in
soon.

If you find something without a patch, I'd go ahead and confirm that the
issue is real, and then go ahead and try to fix it! Looking through Django's
source and fixing things is usually good fun.

In the spirit of Wikipedia, "Be Bold".

Cheers,
Eric

On Sun, Oct 3, 2010 at 9:11 PM, Laurent Luce wrote:

> Hello,
>
> I added the localflavor for Belgium as my first contribution. I would
> like to contribute more code wise. I looked at the tickets with
> milestone 1.3 and with no patch. It is hard to know what is critical
> and where help is the most needed.
>
> Can someone tell me what tickets require immediate help and are not
> too complicated for a new contributor. I don't mind spending 2-3 days
> before Oct 18th. I have been using Django for 2 years and I am quite
> familiar with the basics like views, models, templates and forms.
>
> Please let me know.
>
> Laurent
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: Application, tempaltetags and namespace

[Eric Holscher]

Cody Soyland has also done some work on this in a reusable app, which might
be useful as a starting point:

http://github.com/codysoyland/django-smart-load-tag

Cheers,
Eric

-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: A prompt 1.2.3 release

[Eric Holscher]

> There was a hudson server running IIRC, but
> http://hudson.djangoproject.com/ is not responding to me.
>
>
I took the hudson instance down because nobody was using it and it was
costing me a decent amount of money to run per month. I still have the
images around on Rackspace Cloud if the DSF or anyone actually wants to pay
to have good CI.

Just as a data point, I took it down about a month ago, and people only just
noticed during the sprints. I don't know how to fix that particular problem.

Cheers,
Eric

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

Re: Accessible Command Output using self.stdout & self.stderr

[Eric Holscher]

>
>
> Q1. Should I create a separate, new module with my tests in it, or
> just add tests to an existing module? If an existing one, how do I
> determine which one?
>

It depends if your work is similar to anything else that is already in the
repository. I don't think that the stdout and stdin changing have explicit
tests -- although they are tested implicitly by being used in other tests.


>
> Q2. In attempting my first test one change, it seems as though the
> changes had had no effect. Have I missed some vital understanding...
> I changed the last line of management/commands/flush.py thus
>
> -print "Flush cancelled."
> +self.stdout.write("Flush cancelled.\n")
>
> and created a basic test thus:
>
>def test_flush(self):
>new_io = StringIO.StringIO()
>management.call_command('flush', verbosity=0,
> interactive=True)
>command_output = new_io.getvalue().strip()
>self.assertEqual(command_output, "Flush cancelled.")
>

You need to pass in your custom stdout into the call_command function. You
can see[1] where it takes those inputs and assigns them to your provided
values.

[1]
http://github.com/django/django/blob/master/django/core/management/base.py#L216

Cheers,
Eric

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

Re: New context template tag

[Eric Holscher]

I usually use James Bennett's django-template-utils for this purpose. It has
a nice, simple implementation:

http://bitbucket.org/ubernostrum/django-template-utils/src/tip/template_utils/nodes.py#cl-11

It still requires the annoying Node/function split though.

I know there have been a multitude of third party attempts at improving
Django's template tags, and I think it's commonly agreed that they are one
of the more boilerplatey bits. Sadly none of the third party libraries have
really become defacto, so it's hard to think about including any of them in
core. It does seem like a place that could use some expose either in the
docs or in the general community though.

Cheers,
Eric

On Thu, Jul 22, 2010 at 9:26 AM, Alex Robbins  wrote:

> I am a huge fan of simple_tag and inclusion_tag. They take a common
> template tag use case and make it very easy to write. It seems like a
> common use case that isn't represented is adding a value to context. I
> find myself writing tags to add a variable to context very often and
> it seems like we should be able to abstract this out.
>
> I'm thinking it would work like this, but would love to get feedback
>
> @register.add_to_context_tag
> def tag_name():
>do_some_python()
>return context_value
>
> This would turn into a tag that worked like this:
>
> {% tag_name as variable %}
>
> Which puts context_value into the context as variable.
> 
>
> It could optionally take takes_context, and work like this. This would
> make context the required first argument to the function, like
> inclusion_tag.
>
> @register.add_to_context_tag(takes_context=True)
> def tag_name(context):
>do_some_python_that_needs_context(context)
>return context_value
> --
>
> Finally, it could take arguments like simple_tag or inclusion tag.
>
> @register.add_to_context_tag
> def tag_name(some, arguments, it, takes):
>some_func(some, arguments)
>return context_value
>
> which would yield a tag that worked like this:
>
> {% tag_name some arguments it takes as variable %}
>
> -
> Is this a use case other people have? Can anyone think of a better
> name than add_to_context_tag?
>
> Thanks,
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: Django's testing infrastructure

[Eric Holscher]

Awesome response!

Thanks for the offering of support everyone. Luckily, with hudson, it's
pretty simple to get this all set up. We basically just need to figure out
what the infrastructure looks like.

I don't know if it's going to make more sense to try and set up dedicated
Database servers, or try and set up each client to have the necessary
databases running on each one.

Currently, all I need for a slave machine is a box with a publically
accessable IP, with an account with the Django Testmaster's key on it.
Hudson will take care of everything from there, at least on the Django side.

Hudson will ssh in and pull down Java if necessary, then run itself as a
client. It seems we will need to have some kind of standard setup for the
databases, with either local connections being let through without auth, or
with a standard username and password (maybe django/django), so that we can
do the database operations.

If anyone has much experience here, I'll probably be doing some benchmarking
to figure out what kind of app to database server ratio we need, and what
makes sense in that regard.

I'll give this some more thought this weekend, and try and email everyone
who has offered support. I know there is a django-buildbots mailing list
that never got used last time we did this, i dunno if we want to keep the
conversation here and more public, or put it over there and keep the
archives around for setting stuff up.

Thanks again for all the offers, it's really great, now we just need to
figure out how to scale this up without using lots of human hours in the
process.

Cheers,
Eric


On Fri, Feb 26, 2010 at 1:08 PM, Mikhail Korobov wrote:

> That's great news, thanks!
>
> A very minor issue: web server returns 'Content-Type:text/
> html;charset=ISO-8859-1' header for this page:
> http://hudson.djangoproject.com/monitor/?
> but the actual page encoding is utf-8 so there are strange symbols
> instead of translated strings.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Django's testing infrastructure

[Eric Holscher]

Hey everyone,

During the sprints, I worked to set up a hudson instance for Django. This is
hopefully going to be the way that we are going to go forward for now with
doing continuous integration for Django. I have a pretty good setup going
currently, and want make it really fantastic. At this point in time, what we
really need now is some more hardware to be able to run tests on.

The current setup is hosted at: http://hudson.djangoproject.com/

Currently, I have tests running on the following architectures:

Django trunk:

Solaris:
Python 2.4-2.5
Databases: sqlite, postgres, mysql

Ubuntu:
Python 2.5-2.6
Databases: sqlite, postgres, mysql

Django 1.1.X:

Solaris:
Python 2.5
Databases: sqlite, postgres

This gives us pretty good coverage currently, but the whole point of doing
CI is that we catch bugs on other platforms we wouldn't normally run on.

What we need
===

So I'm looking for people who can offer other boxes that they would like to
see tested. Currently the big ones we aren't covering are Windows boxes, and
the Oracle backends. There are lots of other permutations that we could be
testing against (Different python runtimes being a good example).

However, we don't want to get in a situation where boxes that people have
set up just disappear. So, I'm only currently looking for machines that
people would be able to dedicate to the effort. We would require a
django-testing user account on the box, with our SSH key on it. There would
also be a team of trusted users, who would have access to this key and thus
your machine.

We want the build farm to be stable and useful, and in the past we have had
too much trouble having machines just disappear.

Requirements
===

Currently the hudson requirements seem to be about <1GB of disk space, with
512MB of ram. I'm also looking into some pony build/barn based alternatives
that would knock the memory requirements down pretty substantially. However,
for the current 1.2 release it looks like hudson is how we're going to make
it going forward.

Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so
another way that we might be able to get this going is to be able to have
donations to the DSF, and have them get some dedicated rackspace boxes.
However, for now, I'm hoping that we can cobble together enough stuff to get
1.2 tested really well.

Feedback
==

If you have any thoughts on CI, or any advice, I would love to hear it. I'm
trying to make our Continuous Integration setup really kick ass, so feedback
is necessary to do this. I have some notes and ideas that I have been
recording while setting things up over at the pycon etherpad:

http://pyconpads.net/django-testing

Let me know if you have any thoughts, questions, or concerns.

Cheers,
Eric

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

Re: Serialization of single object instead of only querysets.

[Eric Holscher]

Use Django Piston. It will make your life a ton easier.

Cheers,
Eric

On Wed, Feb 17, 2010 at 11:48 AM, orokusaki wrote:

> Addendum: I might be simply abusing `serialize`. I'm using it as a
> Django compatible `json.dumps` in order to provide a JSON API from my
> models to my JSON-RPC client. There seems to be no more extensible
> way. If this isn't one of the intended uses, let me know and I'll
> leave it alone. Again I apologize for any apparent allusion of
> hostility towards Django or the developers. I'm your #1 fan (ran here
> as fast as I could from RoR a year ago).
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: Django Design Czar

[Eric Holscher]

>
> I'm opposed to this.  Firstly, unless I've missed something whoever
> gets the position, would definitionally get it before they've done
> anything!  This is completely antithetical to the spirit of open
> source, meritocracy.  Why should design be treated any different from
> other changes to Django?  Changes to the design of the admin should be
> handled in the same way as any changes, for a large change someone
> writes up a proposal, starts work, asks for review, finalizes, and it
> gets committed.  That being said there is no reason a designer
> couldn't have a commit bit, Wilson certainly does, but they'd have to
> earn it the same way anyone else does.  We don't need a formalized
> process to get input from designers we trust, I ask for review from
> tons of people who have no formal standing in the Django community
> when I have questions that pertain to their area of expertise.
>
> In conclusion, there is 0 reason design needs to be treated different
> from a procedural perspective.
>
> Alex
>

First off, there are designers who have contributed great amounts of
stuff to the Django community. Nathan Borror has his Basic Apps (which
interestingly is a designer contributing code, because that's what he
can contribute easily). The Grapelli team has that project which
represents a large amount of open source code in the design realm
around the project. There are countless others that have put in the
time, and helped out around here. It's not like we're going to take in
some random designer, these are people that we know and trust.

I agree that this should be treated in the same way as development, is
that not what we're proposing? We have the same role for a designer on
the core team as for a developer. This seems like we are doing the
same thing? It's not like the Czar/Core designer person will be able
to just make commits to the code base whenever they want with no
oversight. They will be just like a normal committer, people will be
able to veto things and everything else. It just means that we have
people who really know what they are talking about with design to make
those decisions.

A similar idea is when Simon asked for feedback on the security issues
with Django's signing infrastructure. We don't have experts on the
team to make those calls, so we need to bring in people who are
knowledge in that area. If there was someone in the community who has
contributed a lot, and knew a ton about security, it would seem like a
no brainer to make them a committer, with a Czar-like power over
security issues. I am merely proposing we do the same thing with
design.

Cheers,
Eric

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

Re: Django Design Czar

[Eric Holscher]

On Sat, Feb 6, 2010 at 6:26 PM, j...@jeffcroft.com wrote:

> First off, I'm generally on board with everything you've said here.
> Only three points/questions I'd like to make:
>
> 1. I wouldn't say "Wilson is out of the picture" without talking to
> him first. I know he's a busy man and my impression is that he doesn't
> have time for this right now, but I'm certainly not going to speak for
> him on that matter. Hopefully he'll speak up and let us know (I do
> know he's been following this discussion, at least casually). I
> totally agree that what we're really talking about now is find his
> successor, but let's not start doing so without confirming with him
> that he doesn't still want this position -- in my opinion, he should
> have first dibs on it if he wants it.
>

Totally agreed. I think that Wilson's input will be very valuable in this
process. He is the one who was around and knows the development process at
World Online that allowed the current admin and templates to be formed. I am
really curious what exactly that is.

I don't want him to feel like we're pushing him out in any way. He has a
brilliant designer, and his input is totally appreciated. I think that he is
already implicitly part of this team of core designers, being a core dev and
a designer, if he has the time. (I like this terminology, "core designer",
since it doesn't imply one person, and everyone immediately knows what it
means).



>
> 2. Is there value in having more than one "design czar?" As in, would
> it be better to have a small team handling this rather than one
> person? I'm not sure I know the answer, but I do worry that any one
> person sets us up for the situation we're in with Wilson -- where
> someone is the "leader", but doesn't really have the time or resources
> to do that job (either temporarily or permanently). I'm not sure what
> my own opinion is one this one, yet, but I thought I'd rase the
> question. Clearly we don't need a ton of people, but maybe a few?
>
> 3. On the topic of Wilson: let's be clear that none of this is his
> fault. He did a spectacular job on the admin interface, and never
> formally received a "design czar" like position in the community that
> I know of. He's busy like many of us, and he hasn't let us down at
> all, in my opinion.
>

Totally agreed. Like in my original post, this is open source. Nobody is
required to do anything. He has given us so much work that I am grateful
for, and Django is in a better place because.

 It's more of a social signal that we really do care about design, and
actually have the people who can step up and do something about it. Wilson
was that person in the beginning, being the defacto person who deals with
design decision for the project. I agree he was never appointed, but that is
how things worked. If we are trying to establish process, or ideas about how
to perform a similar role, then the only thing that we have to look at is
how it was previously done.

Luckily we have an excellent model of how things worked previously, and they
seemed to work pretty damn well. So hopefully we can emulate that going
forward, and produce similarly awesome results.

Cheers,
Eric

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

Re: Refining Django admin look proposal

[Eric Holscher]

I went ahead and replied to this on my blog[0]. I'll copy it here for
completeness.

[0]:
http://ericholscher.com/blog/2010/feb/6/role-designers-django-community/

There has been a recent discussion on the Django Development mailing list
about the role of designers in the Django community. I think that this is an
interesting discussion that can come from this, and I would like to explain
my thoughts on the issue.

This discussion came up in the context of redesigning the Django Admin,
which everyone knows and loves. The UI is growing a bit out-dated, and there
was talk of working to clean it up. This then turned into a discussion about
how design proposals and improvements aren't taken as seriously as they
should be by the community. I think there are a number of reasons that this
happens, and I would like to take a look at them. My purpose here is to
start a discussion about how to better integrate designers into the
community, because they are a vital part of making our world more beautiful
and efficient.

I don't trust myself to judge your work
===

The normal process for changes that go into Django is that a proposal is
sent to the mailing list. There is a discussion that happens around them,
and then if the code is produced, and it works, it gets committed. For
design changes, I don't reply to these messages, because I don't have the
skills or knowledge to judge the work. I think that a lot of people on these
lists are in the same boat.

When someone sends a proposal to the list, and it doesn't get any replies,
that feels like rejection. This happens more than it should, but it isn't
anyones job to respond to these messages and say "sorry, I'm not qualified
to critique your work". This happens with code proposals too, but I think it
may happen more with design. This leads to designers forsaking the mailing
list, and this problem perpetuates itself, by not drawing designers into the
community.

Design is not special, except when it is



Part of the problem that seems to have come forward is that there is a
feeling that design is "special". That it should be treated somehow
differently in the process. As we know from history, even with all good
intentions, different is never equal. So I think that we should work to fit
design into the current scheme of how things work, instead of trying to
adopt new ways of dealing with it.

When I look at the current Core Developers of Django, I don't see many
people who are designers. As I said above, that fact that very few of the
current core developers are well versed in the design realm, really hurts
inclusion of design changes. This creates a lot more friction in the process
of getting design changes into the code base.

I don't know if this idea is crazy, but should we have the concept of a
"core designer". These would be people that the community trusts and knows
have good taste, that would be an obvious person to make these design
choices. I think that there is a problem when I have a design change for
Django, and I really don't know who to talk to. There is an obvious
authority (BDFL) for code changes, but I don't know if Adrian and Jacob are
really the correct people to making these judgment calls on design?

I realize that this is open source, and "core designers" would be the same
as developers, just people who care about the direction of the projects
design. However, I think that having more design oriented people in the
community in a more direct fashion would make it more obvious that design
changes are welcomed and seriously considered.

I don't know how far we need to go down the path of making this explicit.
However, most of the documentation about contributing is explicit about
"code". This is another of those lines, where I don't know if it makes sense
to be explicit about design, having a "design" section in the contributing
documentation, or if the implicit knowledge of core designers will make it
obvious
that we mean design changes there too.

The actual process
==

I don't want to talk about the actual design process, because well, I really
don't know how it works. I think that once we integrate designers into the
community better, the process for design will naturally fall out better.

Conclusion
==

I would like to point out that Django has some of the best designers of any
open source community out there. I am lucky to work with a number of them on
a daily basis, and I really think that they make our community special. So
thank you guys for sticking with us.

This is a place where I could see Django leading the way in how to integrate
design into the open source development process. Let's make a grand
experiment, and see how it works out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this gr

Re: Getting Problem in connecting mysql (Help me please )

[Eric Holscher]

Hi,

Django Developers is for development on Django. For usage questions you want
django-users: http://groups.google.com/group/django-users

Cheers,
Eric

On Thu, Jan 28, 2010 at 8:48 AM, rokson  wrote:

> This is kiran .
> i am new to django fw.i installed django fw and trying to connect
> mysql which is installed in localhost.i am using python 26.i modified
> settings.py according to the mysql db.
> when i am running server. i am getting the fallowing error.
>
> plese help me..
>
>
>
>
> C:\kiranproj\myappone>python manage.py runserver
> Validating models...
> Unhandled exception in thread started by  0x013079F0>
> Traceback (most recent call last):
>  File "C:\Python26\lib\site-packages\django\core\management\commands
> \runserver.
> py", line 48, in inner_run
>self.validate(display_num_errors=True)
>  File "C:\Python26\lib\site-packages\django\core\management\base.py",
> line 249,
>  in validate
>num_errors = get_validation_errors(s, app)
>  File "C:\Python26\lib\site-packages\django\core\management
> \validation.py", lin
> e 22, in get_validation_errors
>from django.db import models, connection
>  File "C:\Python26\lib\site-packages\django\db\__init__.py", line 41,
> in  e>
>backend = load_backend(settings.DATABASE_ENGINE)
>  File "C:\Python26\lib\site-packages\django\db\__init__.py", line 22,
> in load_b
> ackend
>return import_module('.base', backend_name)
>  File "C:\Python26\lib\site-packages\django\utils\importlib.py", line
> 35, in im
> port_module
>__import__(name)
>  File "C:\Python26\lib\site-packages\django\db\backends\mysql
> \base.py", line 13
> , in 
>raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
> django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb
> module: No mo
> dule named MySQLdb
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: Call for comment: #12624 Class based test runners

[Eric Holscher]

Saw this go in, and it gets a huge +1 from me as well. However, I know that
in the past we have talked about adding other things to the test runner
(like coverage, etc), so it would seem like now would be a good time to
recommend accepting **kwargs in your custom test runners, so that when we
add in more abilities in the future, we don't blow up people's old test
runners that they have that don't support new options.

Otherwise this patch looks good, thanks for the work Russ.

Cheers,
Eric

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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Eric]

Seems this thread is saying a few things:

1) It's already there with slice or using a CSS hack (eek!)
2) You should never truncate text on character boundaries anyways
3) Nobody is asking for it

I'm new to Django and my first order of business was creating a
truncate filter because I couldn't find one.  I also found it pretty
odd that it wasn't supported out of the box.  I don't think slice is
the same thing since ellipses are important in this case and adding
conditionals in templates to accomplish this is cumbersome and sloppy.

I also feel the argument that there is no reasonable scenario for
wanting to truncate text on character boundaries is pretty arrogant.
I've found many situations where this is desirable -- like the long
file paths mentioned earlier.

I joined this group, just so I can ask for it to be added to core.  It
doesn't look like I'm alone.

I don't understand the argument for not including it.  It's pretty
obviously wanted and it's not going to turn journalism on it's ear.
It would appear there is also very little cost to including it.

Eric

--

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

Improving (and testing!) bash completion

[Eric Holscher]

Hey all,

I recently was looking for a way to add bash completion to a management
command that I made. With changeset 11526[0] during the djangocon sprints,
bash completion was moved from bash into Python. Now there is a super basic
bash script that calls django-admin.py with the correct environment for it
to autocomplete.

Now that the code is in Python, this lets us do a lot more with it. As
implemented, a custom management command's options (--settings, --list) will
be autocompleted. There is currently no way to define arguments to your
function that will be autocompleted. I went ahead and looked through the
code today and wrote up some proof of concept code that does just this.

What I did


First thing I did was write tests for the current behavior[1]. No tests were
written for the original commit, so if nothing else, these tests should be
commited. The link there works for the current environment, then I added a
few more tests that test my changes as well.

After that, I implemented a basic API for declaring a completion in a
Command class[2]. I will describe here the implemented API. I'm hoping that
people have some ideas about the correct way to implement this.

Currently, your Command class will define a complete() function along with
your handle() function. The complete() function can then return two
different things. In the simple case, it can return a simple list of
arguments that it expects to be able to handle. These will be passed along
to the bash completion, and complete appropriately.

So for example if your custom command 'check_site' had a complete() command
that returned ['ljworld', 'kusports', 'lcom'], and on the command line you
did `django-admin.py check_site ljw`, it would return ljworld.

The more complex case is where you want to be able to define multiple
positional arguments for a command. Currently, this is implemented by
returning a dict with the key being the number that you want to complete
(this sucks. So you could do something like:

def complete(self):
return {
'0': ['ljworld', 'kusports']
'1': ['year', 'week', 'day']
}

Then you would be able to do `django-admin.py ljworld ye` and it would
return `year`.

Currently there is also special casing for returning All Installed Apps, and
All Installed Commands. I went ahead and made a magic symlbol "APP_NAME" and
"COMMAND_NAME" that will evaluate to these lists. Both of these APIs seem a
bit hacky.

So currently I am thinking about making the following changes to make this
stuff a bit better.

Proposal
===

I think that instead of special casing[3] the commands that take an APP_NAME
etc., we would put the complete() function on the BaseCommand, and then for
built-in commands that want custom bash completion, use the proposed API to
define it.

Instead of using simple strings for APP_NAME and COMMAND_NAME, we put these
as constants on the base command class. These could either be special cased
in the bash completion script, like currently, or actually make these
evaluate to the actual list they represent. Computing both of these values
isn't processor intensive, so it would make sense to just have them there.

I don't know what exactly we should do to represent commands that want
control over specific arguments. The current dict with keys of ints seems
silly, but I don't know a much better way. Perhaps represent this as a list
of lists, where index 0 would be the same as the dict['0'].

This would make a basic class end up looking something like this:

def complete(self):
return [
 ['awesome', 'sweet'],
 BaseCommand.SUBCOMMANDS,
 BaseCommand.INSTALLED_APPS,
]

Please let me know what you all think, and what I have missed. Implementing
these changes would resolve a lot of the special casing in the bash
completion, and turn it into a real API that is useful for management
command authors. I think that this is a big win. Bash completion is one of
those things that is super useful, but a damned pain to implement.
Abstracting it this way would make a lot of our commands grow bash
completion I would bet.


[0] http://code.djangoproject.com/changeset/11526
[1]
http://github.com/ericholscher/django/commit/eceda439ab1a950230bd5f792d3f8baef86a56a7
[2]
http://github.com/ericholscher/django/commit/b48b261d2533b45fd7bb955e50869aa1f41bab7b#L0R330
[3]
http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py?rev=11526#L313

-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

--

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

Re: Regularly-scheduled Django sprints, first December 11 - 13

[Eric Holscher]

I would be up for getting one together in Lawrence. Our offices at LJ World
have always been a good place in the past, and I'm sure we can use them
again.



-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: Proposal: Tutorial Refresh

[Eric Florenzano]

I've done this before: http://thisweekindjango.com/screencasts/
( http://github.com/ericflo/startthedark )

I can attest, from the amount of feedback that I've received about
that series of screencasts, that building an entire website from the
ground up is extremely valuable to beginners.  It's also a fairly
massive amount of work.  There's a lot that's changed in the Django
ecosystem since those screencasts, so I'm excited about the prospect
of a fresh new tutorial.

Some lessons I learned along the way:

* Develop the entire site first, and then deconstruct it into the
pieces

My first attempt I didn't do this, and I ended up having to scrap it
and start over after having built the whole site.  This will save you
so many headaches later down the line.

* Actually launch the site somewhere

Last week or so I forgot to renew the startthedark.com domain, and (to
my surprise) I've gotten several e-mails from people about it.  People
apparently really do go to the site itself to see it in action before
watching the screencasts.

* Have the bits and pieces of code in-line with the tutorial, but also
provide a full checkout of the entire site

A lot of what people need to know can be contained in the tutorials,
but what some people need is to actually see the full picture--
everything and how it all fits together, down to the minute details.
This may be less of a problem now with Pinax on the scene, but that
was one major piece of feedback that I had was that people liked being
able to download the whole source tree.

Hrm, I feel like I have more battle scars, but right now I can't think
of anything else.  I'll be around so feel free to ask me any questions
or whatever.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Model.objects.raw() (#11863)

[Eric Florenzano]

> So my question, and this is something I've been thinking about a lot
> of the proposals lately is: why should this be in Django itself.

I couldn't agree with your sentiment more, in the whole.  In fact, to
me, until now all of the proposals aside from Simon's seem better
outside of Django than inside of it.

That being said, this proposal is actually something that I think fits
well within Django core itself, as it really is a logical extension of
the core functionality of the ORM.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Adding signing (and signed cookies) to Django core

[Eric Florenzano]

A big +1 on signed cookies, and I like the direction the discussion is
going.

Also, I hope this doesn't derail this discussion, but I hope after
signed cookies are added, auth can be made to optionally use signed
cookies instead of sessions.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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 for 1.2: built-in logging with django.core.log

[Eric Holscher]

I have looked into Logging before for another project, and I found that
SQLAlchemy's support seemed to be a pretty good model to follow. They define
all of their loggers under the sqlalchemy namespace, and then you can
configure different handlers for different things[1]:

import logging

logging.basicConfig()
logging.getLogger('sqlalchemy.engine').setLevel(logging.INFO)
logging.getLogger('sqlalchemy.orm.unitofwork').setLevel(logging.DEBUG)

I think that this would be necessary to have in Django, so that for
instance, I could listen to the django.orm logs, and not the django.http, or
listen to them with different handlers/levels.

Their implementation[2] is a little confusing to me, but I think that having
some prior art like this will allow us to better understand what we need,
and how to accomplish it, so I thought I would throw it out there.

1: http://www.sqlalchemy.org/docs/05/dbengine.html#configuring-logging
2:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/log.py

-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

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

Re: Proposal for 1.2: built-in logging with django.core.log

[Eric Florenzano]

On Sep 17, 1:25 am, Simon Willison  wrote:
> 1. We'll be able to de-emphasise the current default "e-mail all
> errors to someone" behaviour, which doesn't scale at all well.

I'm a big fan of this proposal, for exactly this reason.

+1

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Question on ticket triage process

[Eric Holscher]

At first glance, tests and documentation. Everything needs both of these
things before they go into trunk. Having a complete patch like that will
make it a lot easier for someone to see what you're doing, and verify that
you have fixed it.

Cheers,
Eric

--~--~-~--~~~---~--~~
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.admindocs need some love.

[Eric Holscher]

On Thu, Aug 27, 2009 at 5:03 PM, Alex Gaynor  wrote:

>
> On Thu, Aug 27, 2009 at 4:03 PM, Justin Lilly
> wrote:
> > Hey guys.
> >
> >  I started writing some docs for another developer today and hit a few
> > issues with admindocs that I plan on sprinting on for DjangoCon. I'm
> > hoping anyone else with complaints / ideas will voice up, though my main
> > impetus for the post is to announce that I'm going to do it so I
> > can't back out. ;)
> >
> > Things I plan to address:
> >
> > 1. No tests.
> > 2. No docs.
> > 3. You can't seem to cross-link to views without the link being
> > app.package.func . I'd like to see it at least configurable.
>
> I've actually got a patch that fixes this on my github django repo in
> the "admindocs" branch.
>
> > 4. ManyToManyFields don't show up.
> >
>
> I don't see this problem, for example User/Group show the relationship
> in both directions correctly, since you clearly don't see it there's
> probably some more debugging work needed here to figure it all out.


Yea, James committed this before 1.1 went out.

http://code.djangoproject.com/changeset/11128
http://code.djangoproject.com/changeset/11127

Cheers,
Eric

--~--~-~--~~~---~--~~
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: 1.2 Proposal: Add a few more tutorial steps

[Eric Holscher]

On Fri, Aug 7, 2009 at 10:05 PM, Russell Keith-Magee  wrote:

>
> Add me to the same list. Initial drafting is always the painful bit
> for me, but if someone wants to get some ideas together, I'm happy to
> help edit, proofread, or give feedback.


I think another good idea would be trying to incorporate some of the
existing tutorials that are outside of the docs (on blogs and other
resources), back in somehow. I don't know if this is an 'external links'
type section, or asking people if adopting their content into the docs would
be okay with them, and have them be part of the official docs.

A few other ideas that haven't been explicitly mentioned, but are
> probably worth a tutorial:
>  * Testing applications


+1, been meaning to do this for a while. I have the beginnings on my blog,
just need to get it into shape for the actual docs. So put me down for the
1.2 time frame on this one.

Cheers,
Eric

--~--~-~--~~~---~--~~
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: limiting admin inlines by limit_choices_to

[Eric]

On May 22, 5:38 pm, mrts  wrote:
> Looks like a general refactoring of admin queryset handling is needed.
> That would also cater for this use case (InlineAdmin objects
> supporting queryset() would solve your case).
>
> Seehttp://code.djangoproject.com/ticket/11019andhttp://code.djangoproject.com/ticket/10761.


Aha, interesting... Thanks for the links.

E

>
> On May 22, 10:24 am, Eric Abrahamsen  wrote:
>
>
>
> > I've got a Model A with a foreignkey to Model B, which is limited to
> > certain instances of Model B using limit_choices_to in the foreign
> > key. If I set up the admin so that Model A instances are editable
> > inline through Model B instances, all Model B instance change forms
> > get forms for Model A inlines, even those that should be excluded
> > according to the limit_choices_to. These Model A inlines can be saved
> > to Model B instances, even when they shouldn't.
>
> > I'd like to open a ticket for this and look into providing a patch
> > unless
>
> > 1. this is a case of "just make your own admin functionality"
> > 2. it's otherwise hard or messy or undesirable.
>
> > Does this seem like an acceptable idea?
>
> > Eric
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

limiting admin inlines by limit_choices_to

[Eric Abrahamsen]

I've got a Model A with a foreignkey to Model B, which is limited to
certain instances of Model B using limit_choices_to in the foreign
key. If I set up the admin so that Model A instances are editable
inline through Model B instances, all Model B instance change forms
get forms for Model A inlines, even those that should be excluded
according to the limit_choices_to. These Model A inlines can be saved
to Model B instances, even when they shouldn't.

I'd like to open a ticket for this and look into providing a patch
unless

1. this is a case of "just make your own admin functionality"
2. it's otherwise hard or messy or undesirable.

Does this seem like an acceptable idea?

Eric
--~--~-~--~~~---~--~~
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: #9282 (comment moderation features) and Akismet removal

[Eric Florenzano]

The Akismet module seems to me to be similar to a Memcached cache
backend.  Yes, it's coupled to a single implementation, but it's the
canonical implementation--note that the only competitor, TypePad
AntiSpam [1], is "100% Akismet API compatible".

> James, this is something that can be added later. This is progressive
> enhancement of the functionality and *if* (not a given) we take what's
> in #9282 now without blocking on every feature that might be possible or
> popular, it won't be a shame. It isn't a half-baked implementation, it's
> just leaving the door open for more additions in the future.

I don't really understand this argument.  Maybe I'm not parsing it
correctly, but I read this as "Your implementation is good, but let's
not add it now so that we can add it later", which seems a bit
strange.

Thanks,
Eric Florenzano

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

Re: Proposal: enable CSRF middleware by default

[Eric Florenzano]

> Too late now since it's already committed, but I've got some serious
> reservations about this one. More development effort should have gone
> into improving and refactoring the middleware before it got
> automatically enabled.

I agree with James here.  With apologies to Luke, the CSRF middleware
needed to be more bulletproof before it was turned on by default.  I
can't count the number of times since turning on the middleware that
I've been greeted with the cryptic "Cross-Site Request Forgery attempt
detected" message inexplicably, and every time I try to go and repeat
it, I am unable to do so.  I suspect that after 1.1 this will be the
most common FAQ/Complaint, is people won't understand and will get
these types of messages often.

Also, I ran into the problem myself where huge swaths of my tests
failed due to the CSRF middleware.  It took me a bit to realize that
it had to do with the CSRF middleware, and if it tripped me up, it's
going to trip up other users as well.  If we're going to ship CSRF
middleware on by default, I propose that we take a second look at the
wontfix status of tickets like #9172.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: Multiple Database API proposal

[Eric Florenzano]

> To me replication is a major use-case. I suspect most people who move
> beyond single server setup and beyond 10'000 - 20'000 visitors realize
> that replication should just be in place ensuring performance and
> redundancy. In my experience other multi-DB patterns (those that covered
> with `using()` and Meta-attributes on models) are just *less* common in
> practice. So I consider leaving replication to "time permitting" a mistake.

There's a finite amount of time in GSoC.  If he says he will
definitely do it, then something else will probably have to be cut to
make time.  Everything else, however, is prerequisite to implementing
the actual replication strategies.

There are almost two GSoC projects here, wrapped into one.  First
there's the plumbing in Django's core that just needs to happen.
Second there's the actual APIs built on top of that plumbing.  The
former needs to happen before the latter, but in implementing the
latter, some changes will almost certainly need to be made to the
former as assumptions are challenged and implementation details get in
the way.

In any case, I think Alex is the one to do this.  He's got a +1 from
me (not that it means much now that I'm on Malcolm's special list).
Speaking of Malcolm's special list...

> One suggestion Eric Florenzano had was that we go above and beyond
> just storing the methods and parameters, we don't even excecute them
> at all until absolutely necessary.

I wasn't actually making that suggestion, per se.  I was just thinking
out loud that _if_ this type of system were implemented, then it would
open the door for some fun computer-sciency things like performing
transitive reductions on the operations performed on the QuerySet.
That being said, I'm not convinced it's the right way to go because of
its significant added complexity, and because it would make poking
around at the Query object more difficult and generally make the Query
object more opaque.

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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: WTForm should be inbuilt to Django, and make admin & others use it.

[Eric Florenzano]

If anyone else read this and was as confused as I was at first, make
sure to note that this is different than WTForms[1], which is an
alternate form library that took several of its cues from Django's
newforms.

[1] http://wtforms.simplecodes.com/

Thanks,
Eric Florenzano
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

1.1: Ticket #3569 (Enhanced Atom Support)

[Eric Holscher]

Hey all,

I have talked to James Tauber about ticket #3569 which is about adding
better support for Atom to the syndication feeds framework. He has
suggested that if we want to include something along these lines in
1.1 that we should put it in Django along-side the current Atom
support. He has a glue layer that maps the old API to his new (and
improved) API[0], but it hasn't been well tested.

I know a lot of people (myself included) use his atom.py[1] file
instead of Django's  atom feed framework. If we wanted to get better
atom support in 1.1, I'm curious what people think of shipping two
versions of a syndication feed API in this release.

Jacob has marked the ticket as 1.1beta, so I'm assuming this means
that it will be going into 1.1. So the question now becomes, what do
we about the old syndication feed API. I know in the past it has been
mentioned that it should be replaced by something better. It seems
that #3569 is indeed something better. Should we also include the
translation layer (that lets you use the old API with the new atom
code), or just let people switch to the new API when ready?

I think that including the new code in a place like
django.contrib.atom would also be an option, for in the future there
might be more support added for Atompub. There are also some questions
about what happens to RSS in this setup, since it is not currently
implemented in this new code.

Curious what people think about these changes. There is no patch
attached to the ticket, so trimming the code, adding docs, and perhaps
adding a bit more testing[2] would be in order to have it included. I
know James' has said that he would be willing to write it as a patch
to Django, and I would also be willing to help do some legwork to get
it committed.

[0] 
http://code.google.com/p/django-atompub/source/browse/trunk/atompub/atom.py#475
[1] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/atom.py
[2] 
http://code.google.com/p/django-atompub/source/browse/trunk/atompub/test_validation.py

Cheers,
Eric
--~--~-~--~~~---~--~~
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: Object Relational Mapping and REST Web Services in Django

[Eric Holscher]

On Thu, Feb 12, 2009 at 9:35 AM,  wrote:

>
> Greetings Django Developers,
>
> Allow me to introduce myself; my name is Rory Tulk.  I'm a grad
> student at the University of Toronto.  A small team of students and I
> are investigating possible implications of unifying the process of
> specifying object relational mapping configuration and URL & function
> mapping for REST web services, and are intending on using Django as
> our target platform for prototyping.  As a starting point, I'd like to
> elicit opinions from the community on directions this could go in.
> Are there any feature requests outstanding for Django's ORM or Web
> Service support?  Any known pitfalls?
>
> Any input is greatly appreciated.
>
> --Rory Tulk
>
> >
>
Welcome Rory,

This sounds like a neat project. I haven't done anything much like it, so I
don't have any personal advice, but similar efforts have been attempted in
the past. The django-rest-interface seems like a logical place to start,
this was a google summer of code projects that Malcolm Tredinnick mentored:

http://code.google.com/p/django-rest-interface/

Looking back through the history of django-dev will probably get you some of
the design discussion that went on around this project. An example is:

http://groups.google.com/group/django-developers/browse_thread/thread/a121b2ed850c93ab/d370133daeeb4b34?lnk=gst&q=rest+api#d370133daeeb4b34

Hope this helps to get your started.

-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
e...@ericholscher.com

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

Re: Contenttype Generation Inconsistency During Serialization

[Eric Holscher]

On Wed, Feb 11, 2009 at 4:59 PM, jameslon...@gmail.com <
jameslon...@gmail.com> wrote:

>
> This is a great solution; when I wrote this post I was sure no one had
> really run into the problem. I will use this for serializing my DB in
> the future. Though, the last paragraph of your reply states that
> content type doesn't define app_label and model as unique. I believe
> that this is true now, at least mine appears to have a unique
> constraint on it right away.


Ah yes, you're right. I was looking at the model definition, but they're
declared unique in the Meta unique_together.

>
>
> This is still a legitimate issue during serialization, it's great to
> see someone has made steps in the right direction.


Glad it's been helpful. I want to get this into a more generic solution, and
hopefully get part of it into django or a real third party app.


>
>
> On Feb 11, 3:45 pm, Eric Holscher  wrote:
> > On Wed, Feb 11, 2009 at 1:48 PM, jameslon...@gmail.com <
> >
> >
> >
> > jameslon...@gmail.com> wrote:
> >
> > > There is a small road block that makes contenttype a little dangerous
> > > to use during application development. Especially in regards to
> > > serializing your data to different databases. During syncdb the
> > > contenttypes are generated in a way that makes regeneration at a later
> > > date inconsistent with the previously generated primary keys.
> >
> > > The contenttype IDs can be different depending on when your syncdb was
> > > run in the development of your application. In addition, loaddata and
> > > dumpdata are prevented from working correctly if the contenttypes have
> > > already been created (integrity errors).
> >
> > > My use pattern for this is during application development I would
> > > architect all of my data models before adding any explicit indexes.
> > > After the models are complete and data is loaded I will analyze the
> > > use patterns and index accordingly. Since django has no way of syncing
> > > indexes my approach would be to dump the data to a JSON file, drop the
> > > database and use syncdb to create the canonical copy.
> >
> > > My experience was as follows:
> > > 1st Try:
> > >  1. Dump data from old db using management command (dumpdata)
> > >  2. Drop DB and use django to create the database via syncdb
> > >  3. Load data using management command on the new database
> > >  4. Become irritated with integrity errors while the load tries to
> > > import the contenttype table which already exists.
> > > 2nd Try:
> > >  1. Dump data from old db using management command (dumpdata),
> > > excluding the contenttype table (-e contenttypes)
> > >  2. Drop DB and use django to create the database via syncdb
> > >  3. Load data using management command on the new database
> > >  4. Realize all data is completely useless since contenttype's PK's
> > > are not connected to the same models as before.
> > > 3rd Try:
> > >  1. Dump data from old db using management command (dumpdata)
> > >  2. Drop DB and use django to create the database via syncdb
> > >  3. Truncate contenttype table
> > >  4. Load data using management command on the new database
> >
> > > Possible solution that doesn't suck a lot:
> > > I came up with quite a few different ways to handle this, but the best
> > > so far (even thought it's not stellar) is to create a new column in
> > > contenttypes that's a combined column. The combined column would
> > > contain the app_label and model_name.
> >
> > > GenericForeignKey could use the combined column instead of the PK to
> > > keep the references pointing to the same locations. I understand there
> > > are some performance implications here, but it's the best I can come
> > > up with. I would love to hear thoughts on this topic.
> >
> > I have run into this problem as well, and have come up with a basic
> solution
> > (for content types). The code is here:http://dpaste.com/119487/. It is
> > implemented as a serializer, which you would plug into django, and then
> use
> > for serialization and deserialization of models with content types.
> >
> > It is rather simple (only about 10 lines of additional code). When it is
> > dumping data, it checks to see if the field it is dumping is a content
> type,
> > and if so, it dumps a dictionary of app_label and model. Then, when this
> > fixture is loaded back in, it runs a query against the Con

Re: Contenttype Generation Inconsistency During Serialization

[Eric Holscher]

On Wed, Feb 11, 2009 at 1:48 PM, jameslon...@gmail.com <
jameslon...@gmail.com> wrote:

>
> There is a small road block that makes contenttype a little dangerous
> to use during application development. Especially in regards to
> serializing your data to different databases. During syncdb the
> contenttypes are generated in a way that makes regeneration at a later
> date inconsistent with the previously generated primary keys.
>
> The contenttype IDs can be different depending on when your syncdb was
> run in the development of your application. In addition, loaddata and
> dumpdata are prevented from working correctly if the contenttypes have
> already been created (integrity errors).
>
> My use pattern for this is during application development I would
> architect all of my data models before adding any explicit indexes.
> After the models are complete and data is loaded I will analyze the
> use patterns and index accordingly. Since django has no way of syncing
> indexes my approach would be to dump the data to a JSON file, drop the
> database and use syncdb to create the canonical copy.
>
> My experience was as follows:
> 1st Try:
>  1. Dump data from old db using management command (dumpdata)
>  2. Drop DB and use django to create the database via syncdb
>  3. Load data using management command on the new database
>  4. Become irritated with integrity errors while the load tries to
> import the contenttype table which already exists.
> 2nd Try:
>  1. Dump data from old db using management command (dumpdata),
> excluding the contenttype table (-e contenttypes)
>  2. Drop DB and use django to create the database via syncdb
>  3. Load data using management command on the new database
>  4. Realize all data is completely useless since contenttype's PK's
> are not connected to the same models as before.
> 3rd Try:
>  1. Dump data from old db using management command (dumpdata)
>  2. Drop DB and use django to create the database via syncdb
>  3. Truncate contenttype table
>  4. Load data using management command on the new database
>
>
> Possible solution that doesn't suck a lot:
> I came up with quite a few different ways to handle this, but the best
> so far (even thought it's not stellar) is to create a new column in
> contenttypes that's a combined column. The combined column would
> contain the app_label and model_name.
>
> GenericForeignKey could use the combined column instead of the PK to
> keep the references pointing to the same locations. I understand there
> are some performance implications here, but it's the best I can come
> up with. I would love to hear thoughts on this topic.
> >
>
I have run into this problem as well, and have come up with a basic solution
(for content types). The code is here: http://dpaste.com/119487/ . It is
implemented as a serializer, which you would plug into django, and then use
for serialization and deserialization of models with content types.

It is rather simple (only about 10 lines of additional code). When it is
dumping data, it checks to see if the field it is dumping is a content type,
and if so, it dumps a dictionary of app_label and model. Then, when this
fixture is loaded back in, it runs a query against the Content Types for
that object. Then plugs that in for the content type.

This fixes the problem of content types being an ID, and the ID's not
matching when you move across databases (Your try #2).

I have also been working on a more generic solution to this problem. I have
a copy of it on github(1). The approach taken there is similar. When it
loads a ForeignKey field to be serialized, it checks the related model (the
one being pointed to) for any unique constraints. If any of these exist,
then the model is dumped as a dictionary of kwargs containing the key/value
pair for these unique constraints.

The content type model doesn't define app_label and model as unique, which
is a problem for this approach. If this ever gets into django core, it's
going to require a special case for content type things (or some other
approach which I haven't thought of). Having references to contrib apps is
frowned upon, so I think having a third party serializer that does this is
the answer for now.

Hope this helps

1.
http://github.com/ericholscher/sandbox/blob/d32da8c36f257bb973a5c0b0fd8f9bca79062f11/serializers/yamlfk.py

-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
e...@ericholscher.com

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

Re: Rolling back tests -- status and open issues

[Eric Holscher]

On Thu, Jan 15, 2009 at 12:06 PM, Karen Tracey  wrote:

> On Wed, Jan 14, 2009 at 5:35 PM, Russell Keith-Magee <
> freakboy3...@gmail.com> wrote:
>
>>
>> On Thu, Jan 15, 2009 at 5:40 AM, Eric Holscher 
>> wrote:
>> > I think that if there is a plan to ever include fixtures into doctests,
>> then
>> > we should put transaction management into them. We should also decide on
>> a
>> > syntax (__fixtures__ really isn't too bad). This is mostly a bikeshed,
>> where
>> > if it's going to happen, we just need to decide something that works and
>> go
>> > with it. Otherwise we should go ahead and close #5624, and say that
>> doctests
>> > are only for simple cases where you are generating the objects yourself.
>> > This means that we will internally write out doctests that require
>> fixtures
>> > back into unit tests, but this isn't a huge deal.
>> >
>> > I think we should just decide now, and stick with it. I really don't
>> have a
>> > preference, because I don't think that doctests should be used as
>> > extensively as they are. I know a big reason they were used before is
>> > because they were faster, which now a moot point. If we just say "we
>> will
>> > never have fixtures or transactions on doctests", then we can just be
>> done
>> > with it.
>> >
>> > 1: http://code.djangoproject.com/ticket/5624
>>
>> There is two issues at work here.
>>  1) Is #5625 a good idea?
>>  2) Do we need to implement it right now?
>>
>> Regardless of the answer to (1), (2) is the more pressing concern -
>> given that we're days away from a v1.1 feature freeze, and we're
>> probably behind schedule as it is, now isn't the time to start with
>> unnecessary feature creep. As far as I can tell, #5625 can be safely
>> deferred to v1.2 without losing functionality or being boxed into a
>> corner by #8138. Given that there isn't any urgency brought on by a
>> need to meet v1.1 commitments, I suggest that we should defer this
>> discussion to the next planning cycle.
>>
>
> I agree.  As it is now #8138 doesn't change the behavior of doctests, so
> far as I know.  Trying to do the same thing for them as was done for
> django.test.UnitTest code -- running them in a rolled-back transaction and
> preventing them from calling transaction routines -- led to more weird
> errors in the Django test suite.  Given time I'm sure they can be figured
> out, but I think there's some design work involved in order to come up with
> a way for them to opt-out of the change, as TestCases can do by switching to
> TransactionTestCase.  It seems there is similar work to be done for
> extending them to auto-load fixtures, and it would make sense coordinate
> that work so that all Django "doctest extensions" have a similar feel, use a
> consistent mechanism, etc.  But we don't have time to do that for 1.1, I
> don't think.  But I don't think it's necessary to say at this point we can
> never do it.
>
> I'm hopeful #8138 can go in (today -- to make the major feature freeze
> deadline?) for 1.1 pretty much as it is now.  It provides good speedup for
> Django TestCases.  So far as I know doctests are now unaffected by it -- if
> I'm missing something there in terms of the latest patch on #8138 breaking
> doctests please let me know.
>
> Karen
>
> >
>
You both are indeed correct. I certainly think that the current patch can go
in today as presented. The Ellington test suite is passing with a 10x
speedup. We can get it to 40x speedup if we change out doctests that load
fixtures into unit tests (which probably makes more sense anyway). From 2
hours down to 3 minutes is amazing.

Thanks for all the hard work, and I'm really excited to see this going into
Django. Django development will be much improved with this change.

Cheers,
Eric



-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
e...@ericholscher.com

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

Re: Rolling back tests -- status and open issues

[Eric Holscher]

ed by some if code changes are required to use it.
> But I did want to point out that the effects of the re-ordering done to put
> the rolled-back transaction test cases first may be a little more subtle
> than expected, in case that sways anyone's opinion towards requiring opt-in
> for getting the new behavior.
>
> Karen
>
>
> >
> I would also like to point out a kind of edge case. The Ellington test
suite is currently using the approach in #5624[1], where we are injected
fixtures into doctests by declaring a __fixtures__ argument inside of a
doctest. This is currently being run with a patched Test Runner that applies
the fixture (if present), and then calls the doctest.DocTestRunner.run
itself. This is having to apply a flush before every call it loaddata
(basically mimicking transactions, but much slower).

I think that if there is a plan to ever include fixtures into doctests, then
we should put transaction management into them. We should also decide on a
syntax (__fixtures__ really isn't too bad). This is mostly a bikeshed, where
if it's going to happen, we just need to decide something that works and go
with it. Otherwise we should go ahead and close #5624, and say that doctests
are only for simple cases where you are generating the objects yourself.
This means that we will internally write out doctests that require fixtures
back into unit tests, but this isn't a huge deal.

I think we should just decide now, and stick with it. I really don't have a
preference, because I don't think that doctests should be used as
extensively as they are. I know a big reason they were used before is
because they were faster, which now a moot point. If we just say "we will
never have fixtures or transactions on doctests", then we can just be done
with it.

1: http://code.djangoproject.com/ticket/5624

Cheers,
Eric

-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
e...@ericholscher.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
-~--~~~~--~~--~--~---

1.1 Sprints and roadmap

[Eric Holscher]

It looks like January 15 is when the Major Feature freeze happens (and
that is in about 2 weeks). The roadmap[1] says that there will be 1.1
sprints starting in late december, which has come and is quickly
fading. Just figured I would start the discussion on when/where some
sprints will be happening. If we want some kind of decent attendence
before the 15th, these are going to have to be scheduled pretty soon.

Also, does the major feature freeze mean that the features must be
committed, or that they have have significant amounts of work done? (I
don't see any of the "Must have"s for 1.1 having been committed..)

Cheers,
Eric

1: http://code.djangoproject.com/wiki/Version1.1Roadmap
--~--~-~--~~~---~--~~
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: Perl port of the django template system.

[Eric Holscher]

Name it whatever you want. It's your bikeshed.

Eric

On Sun, Dec 21, 2008 at 11:55 PM, Maluku wrote:

>
> DTL seems to be too short...
>
> What about "Dotiac" (DjangO Template Interpreter And Compiler), which
> works as a name and an abbreviation.
>
> Maluku
>
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
e...@ericholscher.com

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

Re: twitvn

[Eric Holscher]

Check out http://twitter.com/DjangoTracker

Eric

On Fri, Dec 5, 2008 at 1:02 PM, David Reynolds
<[EMAIL PROTECTED]>wrote:

>
> Hi,
>
> Since a lot of Djangonauts and Django Developers are using twitter,
> would anyone find it useful to get svn commit messages on twitter?
>
> There seem to be a drop in svn hooks script called twitvn [0] that can
> be used.
>
> I've seen other people following the Wordpress [1] one and thought it
> might be quite interesting and useful to have one for Django.
>
> Thoughts?
>
> 0 - http://code.google.com/p/twitvn/
> 1 - http://twitter.com/wpdevel
>
> --
> David Reynolds
> [EMAIL PROTECTED]
>
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django & memcache hashing

[Eric Holscher]

Just wanted to say that we ran into this exact issue at work the other day
as well. We had the C and Python versions of memcache running, and it was
hashing things differently (to different servers or something as I
understand it). This caused us a good couple hours of confusion. We
eventually figured it out and made sure that each of our boxes had the same
version of memcache.


On Thu, Nov 20, 2008 at 3:01 AM, Ludvig Ericson <[EMAIL PROTECTED]>wrote:

>
> On Nov 20, 2008, at 05:20, Ivan Sagalaev wrote:
> > What concerns me is that this will break the usage of memcached
> > without
> > Django's cache API. I had the need a couple of times to do plain
> > instantiation of memcache.Client and work with it. If it won't see the
> > cache the same way as Django does it would be that very issue, hard to
> > debug, that started this thread.
>
> True, but that's because python-memcached for some reason still uses its
> own hashing algorithm (pure CRC32) while other libraries are more or
> less
> unified in their hashing algorithm. (Wouldn't know about libmemcached.)
>
> *ugh* Why can you never eat the pie and have it. :(
>
> - Ludvig
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.1 feature: unify access to response.context in test client

[Eric Holscher]

Note also, that sometimes the context that you are looking for isn't always
in [0]. I ran into this when I was writing testmaker, and had to hack around
it. Luckily all of my templates used inheritance, so I didn't get bitten by
the dictionary or list of dictionary part.

I did something like this:

con = context.dicts[0]
if 'MEDIA_URL' in con:
con = context.dicts[-1]

Obviously a hack, but it seems to work most of the time.

For my pony request, it would be really nice to have a way to get "user
defined" context. This being things that were passed from views, set in
template tags, (and maybe other places?). That is what the above code is
trying to do. I haven't thought about how to do it, but I agree with James
that some thought needs to be placed into this.

A simple workaround might be to flatten the lists in request.context, but
then keys in the dictionaries might be overwritten.

On Sat, Nov 8, 2008 at 2:56 PM, James Bennett <[EMAIL PROTECTED]> wrote:

>
> The Django test client exposes the Context used to render the returned
> response, so that unit tests can inspect that Context and verify that
> it contained what it was expected to contain. This is all well and
> good, except that there is no consistent way to write tests which do
> this.
>
> When an inheritance chain of multiple templates is used to render the
> response, ``response.context`` is a list of dictionaries,
> corresponding to the Context at each template and so, for example, one
> might want to check ``response.context[0]['some_var']``. But when
> inheritance is not used, ``response.context`` is simply a dictionary,
> leading to a check lik ``response.context['some_var']``.
>
> This makes it extremely difficult/tedious to write truly portable unit
> tests, since a test which passes on one installation of an application
> might fail on another for no other reason than that the type of
> ``request.context`` has changed from dictionary to list, or
> vice-versa, raising spurious ``TypeError`` or ``KeyError`` depending
> on which way it changed.
>
> For a real-world example, consider django-registration: I have a local
> project set up to run its unit tests, with minimal (non-inheriting)
> templates; the test suite accesses ``request.context``
> dictionary-style, and passes. But a user of django-registration
> attempted to run the test suite on an installation which uses
> inheritance, and saw multiple test failures as a result:
>
>
> http://www.bitbucket.org/ubernostrum/django-registration/issue/3/failed-in-test
>
> I believe quite strongly that unit tests, if they are to be useful,
> need to be portable. And currently, it seems the only way to make them
> portable is to include type checks on response.context each time a
> test will inspect the context, e.g.,::
>
>if isinstance(response.context, list):
>self.assertEqual(response.context[0]['foo'], 'bar')
>else:
>self.assertEqual(response.context['foo'], 'bar')
>
> This is painful and ugly.
>
> For 1.1, could we look into unifying the interface to
> ``response.context`` to avoid this sort of problem? Unless I'm
> thinking about this the wrong way, it shouldn't be too hard to
> differentiate dictionary-style access from list-style access, since
> the former -- in the case of a Context -- will always be using string
> keys and the latter will always be using integer indexes.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Decoupling authorization from view

[Eric Drechsel]

Hi Thomas,

Ya, it would be really nice if there was a standard way of handling
authorization for views, so that external code can check if a view is
authorized. I have been doing identically the same thing, except I was
naming the view attribute "authorized".

The current decorators could be modified to set this attribute,
however this is probably unlikely now that 1.0 has hit.

Perhaps you could post your code somewhere so that 3rd-party app
developers can standardize their authorization (git-hub?).

  Eric

On Oct 13, 7:11 am, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The auth-decorators to check for permission are nice, but it would
> be better, if the authorization could be decoupled from calling the view.
>
> My goal: Check if a user can access a view without calling it, because
> I want to disable/hide a link if the user must not call it.
>
> I implemented it in my application, but it would be nice if something like
> this would inside django (This would improve plug-ability of applications)
>
> My implementation works like this:
>
> every view method as an attribute 'has_perm' which takes the
> same args, kwargs like the view:
>
> def myview(request, something)
>      ...
> myview.has_perm=lambda ...
>
> For ease of usage you can set has_perm to True (no access restriction)
> or to a permission string (app_label.perm_codename) or to is_authenticated,
> is_staff, is_superuser.
>
> There is a small helper method for checking if a user/request would be
> allowed
> to access this view and a small middleware to render "403 forbidden" pages.
>
>   Thomas
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Optional {% default %} clause for the {% for %} template tag

[Eric Holscher]

{% for color in patches %}
Bikeshed: {{ color }}
{% default %}
Person who writes the patch decides
{% endfor %}

I like empty/default or else. Use else if your main target is python people.
Use empty or default if your targetting it to designers. It really doesn't
matter which..

On Thu, Oct 30, 2008 at 12:29 PM, Antoni Aloy <[EMAIL PROTECTED]> wrote:

>
> 2008/10/30 Mike Panchenko <[EMAIL PROTECTED]>:
> > +1 for {% empty %}
> >
> > I also think this would be very useful
> >
> > On Thu, Oct 30, 2008 at 6:55 AM, dc <[EMAIL PROTECTED]> wrote:
> >>
> >> How about
> >>
> >> {% for item in items %}
> >> {% otherwise %}
> >> {% endfor %}
> >>
>
> +1 to the otherwise tag :)
>
>
> --
> Antoni Aloy López
> Blog: http://trespams.com
> Site: http://apsl.net
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: dealing with legacy tables without primary key

[Eric]

> I would be surprised if it works with Oracle, unless you replace
> IntegerField with CharField(max_length=18).

I made tests only on sqlite (a trac db).
I mean it ''should'' works with Oracle because Oracle support oid's;
but I have made no test. If someone want to ...

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Eric]

Hi,
i just discover this thread, I am working on this problem; you may
take a look at
http://kenai.com/projects/django-trac/pages/LegacyModule

legacy is a module in my "django hacks trac" (or djac) project; it
aims to deal with
tables with no primary key or with composite pk. It provides 2
methods:

- use of oid field (works on sqlite, oracle, postgres <= 8)
- composite pk (for mysql that provides no oid field)

cheers,
Eric
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: dealing with legacy tables without primary key

[Eric]

On Oct 2, 4:51 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> On Oct 2, 2008, at 10:31, Eric wrote:
>
>
>
>
>
> > Hi,
> > I saw few questions from people who wonder how to manage tables
> > without primary key (when using inspectdb on a legacy db);
> > A great hope is born: I just discovered that this problem could be
> > adressed, at least it works with sqlite:
>
> > just add this field (rowid or oid is the sqlite automatic pk) in the
> > model:
>
> >    rowid = models.IntegerField(primary_key=True, editable=False)
>
> > It works ! it's so simple ! I love django !
>
> > Maybe this tip could be added in the doc; for others sgbd, there must
> > be something similar.
> > And why not put this in the inspectdb command ...
>
> Because it's a dirty, dirty hack.
It is your opinion; what is your solution ? it should interest me,
because this "dirty hack" can only work with sqlite, oracle (and
postgres 8+ with a special configuration), but not with mysql.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

dealing with legacy tables without primary key

[Eric]

Hi,
I saw few questions from people who wonder how to manage tables
without primary key (when using inspectdb on a legacy db);
A great hope is born: I just discovered that this problem could be
adressed, at least it works with sqlite:

just add this field (rowid or oid is the sqlite automatic pk) in the
model:

rowid = models.IntegerField(primary_key=True, editable=False)

It works ! it's so simple ! I love django !

Maybe this tip could be added in the doc; for others sgbd, there must
be something similar.
And why not put this in the inspectdb command ...

cheers,
Eric

PS: I am testing this on the "Django Hacks Trac" project (and I am
testing the new kenai forge too): http://kenai.com/projects/django-trac

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Running tests.py in apps without models.py

[Eric Holscher]

You can just put a models.py there that is empty. A slight hack, but it
should work just fine. (Think of it as __init__.py's big brother :))

Eric

On Tue, Sep 23, 2008 at 2:27 PM, Adam J. Forster <[EMAIL PROTECTED]>wrote:

>
> Firstly I'm sorry if I have posted this in the wrong place, but I
> think that it belongs here and not on the django-users list.
>
> Here's my problem, in most of our projects at work we have an app
> called 'core' which contains modules that are either used by several
> other apps or are not specific/large enough to justify their being in
> their own apps.
>
> Today I needed to write some doctests for a function in core.utils so
> I created a tests.py file inside core and placed my doctest there.
> When I attempted to run the tests using 'manage.py test' I found that
> they were not being run, when I ran 'manage.py test core' I got the
> following error:
>
> django.core.exceptions.ImproperlyConfigured: App with label core could
> not be found
>
> After some digging around in the Django source code I found the
> problem. django.test.simple.run_tests makes calls to either
> django.db.models.get_apps or django.gb.models.get_app to identify
> which app(s) to search for tests. These functions return the models
> module for the app, if the app does not contain a models module it is
> not considered to be a valid app and is therefore not searched for
> tests.
>
> This is not the first time that I have had an app which does not
> contain a models module, and I can foresee that I will do the same
> thing in the future. These apps may not contain models but they still
> have code which needs testing.
>
> So my question is should I file this as a bug and start working on a
> patch for simple.run_tests that checks all INSTALLED_APPS for both
> models.py and tests.py when searching for tests? Or is this something
> which is not likely to change, in which case would I be better off
> writing my own test runner instead?
>
> Kind regards,
> --
> Adam J. Forster
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Django Cheeseshop

[Eric Holscher]

Haha, yea, sorry.

On Wed, Sep 10, 2008 at 11:17 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:

> On Wed, Sep 10, 2008 at 12:12 PM, Eric Holscher <[EMAIL PROTECTED]>wrote:
>
>> Yea, I totally agree with this.
>>
>> I wrote a blog post about how to use setuptools and distutils to
>> distribute your django apps. There is no reason to reinvent the wheel here,
>> especially after what Mark talked about at Djangocon (Django being
>> considered seperate from the Django community).
>>
>
> Did you mean 'Python community' there?  (I did not see the talk, so trying
> to understand...)
>
> Karen
>
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: I want a pony: Django Cheeseshop

[Eric Holscher]

Yea, I totally agree with this.

I wrote a blog post about how to use setuptools and distutils to distribute
your django apps. There is no reason to reinvent the wheel here, especially
after what Mark talked about at Djangocon (Django being considered seperate
from the Django community).

I have been tempted to package other people's apps and put them on Pypi and
then hand over control if they wanted it, but that seemed rather heavy
handed. Some kind of official suggestion, or just a culture of putting apps
up there would be huge. I really think that everyones apps should be up on
Pypi.

Eric

On Wed, Sep 10, 2008 at 10:57 AM, James Bennett <[EMAIL PROTECTED]>wrote:

>
> On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
> >  * create a central app index à la Cheeseshop
>
> Doesn't the Cheese Shop already exist?
>
> >  * create an automated system similar to easy_install for installing
> > apps from
> >   o that central repository
>
> "easy_install django-registration" works fine for me right now. Why
> not encourage people to use standard Python practices for packaging
> and distribution?
>
> >   o either globally to Python packages -- *but under django namespace!
> > *
> >   o or locally into a concrete project
>
> Does anybody else actually do this? Last I checked, Pylons, TurboGears
> and Zope apps didn't install or need to be installed into
> framework-specific locations. Django applications are just Python
> modules, and that's a *strength* from where I sit.
>
> >  * provide app dependency handling like setuptools does for
> >   o python package dependencies (identical to setuptools 'depends')
> >   o Django app dependencies (e.g. 'django_app_depends')
>
> Or just, you know, use setuptools.
>
> >  * bundle the install tool either as a command for manage.py or a
> > separate utility in bin
>
> Or just, you know, install setuptools.
>
> >  * create the solution so that it can be adopted by other projects by
> > clearly decoupling Django-specific functionality (i.e. engage more
> > brainpower and devs)
>
> Or just use the existing packaging and distribution tools Python already
> has.
>
> Have I made my point clear enough yet?
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: innodb with mysql

[Eric Montgomery]

The reason I posted this here is that it seems like it might be a
problem with the way django generates the mysql.
>From what I understand, problems with foreign-key constraints with
innodb can occur if multiple-table updates are run "out of order," so
to speak.  However, I'm definitely not an expert on mysql, so I don't
think I would have much of a shot at figuring out exactly what was
going wrong.
Due to the fact that everything works correctly when I switch to the
myisam engine (and it worked in sqlite on my development machine), it
would seem to be less of a problem with my code as with the sql.

On Aug 21, 10:35 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-08-21 at 07:23 -0700, Eric Montgomery wrote:
> > I'm not exactly sure what's going on here, and I managed to "fix" it
> > by switching my storage engine to myisam, but I figured I'd post
> > something here to see if any has had or is aware of this problem.
>
> Please post support questions like this to the django-users list. This
> mailing list is only for the internal development of Django.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

innodb with mysql

[Eric Montgomery]

I'm not exactly sure what's going on here, and I managed to "fix" it
by switching my storage engine to myisam, but I figured I'd post
something here to see if any has had or is aware of this problem.

I had a blogs.author model that had a foreign key relation to User.  I
created a User and then created an author whose foreign key pointed to
that User.  When I tried to go edit the User, I got the this error:
"Table auth_user_groups doesn't exist."
Sure enough, the tables "auth_user_groups", "auth_group_permissions"
and "auth_user_user_permissions" hadn't been created when I ran syncdb
but they were present on my development machine (which was just using
sqlite).
I then tried to run "manage.py reset auth" to see if I could just drop
the tables and start over, but when I ran that, I got this error:
"Cannot delete or update a parent row: a foreign key constraint
fails."  As best as I could tell, something in the relation between
the User and blogs.author got a little messed up.
I couldn't even manually drop the tables because I kept getting the
foreign key constraint error, so I dropped the database and switched
storage engines to myisam.  After that, I ran syncdb to create all of
the tables.  The above 3 auth tables still weren't there (although the
4 other auth tables were there), so I ran "manage.py reset auth" which
worked this time and that somehow decided to create those tables.
After another syncdb, everything seems to be working fine.

Basically, it seems like if those 3 tables had been created on the
first syncdb, I wouldn't have run into any of these problems, so I'd
like to know why it behaved like it did.  But also, I can't figure out
exactly what was going on with the foreign key constraint error, so to
play that safe, I switched to myisam, although I would like to use
innodb if I can make it work.

If anything in my explanation was unclear (it all happened around 3am
last night), let me know and I can try to clear things up.

-Eric

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: DjangoCon meetup Friday Sept 5

[Eric Holscher]

I think the TWID guys are doing something as well. Might want to combine
groups.

Eric

On Wed, Aug 20, 2008 at 11:21 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote:

>
> I'm planning a get together the night before DjangoCon for people
> going to the conference.  I figured it would be nice to get to know
> each other a bit better before sitting in a conference together all
> weekend.
>
> I'm assuming that most people are going to be staying at the Hotel
> Avante where the block of rooms was reserved for the conference.  So,
> I've talked to the hotel, and they've said that we can use the patio
> by the pool for the meetup.  We can probably fit about 30 people
> there.
>
> If a lot more people show up, or if people aren't staying at the
> hotel, there's a billiard club across the street that's big enough to
> accommodate a larger group.
>
> I've set up a meetup page for the event here:
> http://django.meetup.com/3/
>
> Please RSVP if you're thinking about attending.  If the RSVP's fill
> up, we can move the venue across the street or find some place else.
>
> If anyone else can think of a better place to post this information,
> let me know.  Comments and  thoughts are always welcome.
>
> Jonathan
>
> >
>


-- 
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://www.ericholscher.com
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Community representation, or, #django user "Magus-" needs to go far away

[Eric]

Well, you can teach someone to fish without telling them to "get an
f'n fishing pole".

On Jul 1, 5:25 am, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> On 26-Jun-08, at 7:51 PM, Jeremy Dunck wrote:
>
> >> Then, I tried helping people the way he does for a mere fraction of
> >> the time he does. Answering the same 5 questions 20 times a day  
> >> (ok, I
> >> did it maybe twice) would drive anyone insane.
>
> > +1
>
> +1
>
>
>
> > Yes, it'd be nice if Magus were a bit more polite, but I'd say his
> > patience and dedication are legend.
>
> why should he be more polite? He follows the policy of 'teaching to  
> fish' rather than spoonfeeding. I have several times got flamed by  
> him for getting impatient and giving the answer. I would say that he  
> is the single most important person in the channel. He has even taken  
> the trouble of writing a script whereby he can generate almost  
> instantaneous references to the *relevant* docs. It is easy to give  
> direct answers - difficult, irritating and time consuming to 'teach  
> to fish'. Let him be as rude as he wants, as long as he is there.
>
>
>
> --
>
> regards
> kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/code/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Community representation

[Eric]

The guy is rude.  I never go in the IRC channel to help because he's
there being an ass.

The reason why I fell in love with Django way back in 2005 was because
of the community in #django and I'm worried that he's stunting
adoption because he's turned the channel into #linux.

E.

On Jul 2, 7:41 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> Russell Keith-Magee wrote:
> > On Tue, Jul 1, 2008 at 5:25 PM, Kenneth Gonsalves
> > <[EMAIL PROTECTED]> wrote:
> >> Let him be as rude as he wants, as long as he is there.
>
> > Lets stop this idea before it grows legs. One of the strengths of
> > Django is the community, and one of the reasons the community is
> > strong is because it is approachable for newcomers.
>
> > There's no problem with being blunt or brusque, but straight out
> > rudeness is not appropriate, and it will not be tolerated.
>
> In which case perhaps a change of subject line might be appropriate?
>
> I would say that Magus *is* blunt or brusque rather than rude. His
> approach isn't always appreciated because he won't "spoon-feed" people,
> preferring instead to lead them by the hand (or, occasionally, a rather
> more tender body part). But that's going to make for a more capable
> community in the end, and is better from a learning point of view.
>
> Besides which, sometimes it's amusing to watch the conversations. We are
> a long way from the c.l.perl flaming of newbies. People are definitely
> getting the answers they need, and Magus is a prime distributor of
> high-quality information to the IRC channel.
>
> regards
>   Steve
> --
> Steve Holden        +1 571 484 6266   +1 800 494 3119
> Holden Web LLC              http://www.holdenweb.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django releases

[Eric]

I was in discussions at work on what version to work with on a
enterprise level project with the intent of using 1.0 when it comes
out.

We discussed using 0.96, and tracking trunk.  Both routes mean a lot
of maintenance.

If we stay with 0.96, that means that when 1.0 comes out there will be
a lot of work needed in order to port it to 1.0.  It is inevitable
that the migration will introduce bugs into a stable product.   This
seems like a poor choice.

The other choice was tracking trunk.  Incremental updates and
modifications allows the road to 1.0 update to occur in piecemeal.
This prevents the need for a gigantic undertaking to port from 0.96 to
1.0.  However, the introduction of bugs will still present, they are
just spread out along the history of the project.

There's an illusion of greater stability with tracking truck as
opposed to using 0.96 and porting to 1.0.  With the 0.96 to 1.0 port
it will have a greater number of bugs at one time as opposed to the
same number of bugs spread over time.

With incremental updates the downtime caused by errors introduced by
following trunk will most likely be small enough to be negligible.
However, there is a aspect of the unknown in this route  (which is
despised in enterprise development).  You won't know if the next
update will have crippling bugs in it.

Since there is that unknown we came up with another route. This route
is a delayed trunk update, which is tracking trunk but only updating
to a revision that's a week or two old.  This adds a small buffer to
prevent those the rare crippling bugs from destroying your site.

This delayed update route adds another level of stability that a team
of developers need,  a common base for development.  Since we're all
working on r2110 for example, we all can use that version instead of
each developer using whatever version of trunk they have updated to.
Then in two weeks, we all update to r2201 and work on that until the
next scheduled update.

I'm not certain that this route is perfect, but it seems to be a
compromise of both worlds.  A little of the stability of using 0.96
without the need of a massive port when 1.0 comes out.

Eric.

On Jun 8, 11:11 am, Phil M <[EMAIL PROTECTED]> wrote:
> On Jun 8, 9:27 am, Wim Feijen <[EMAIL PROTECTED]> wrote:
>
> > My vote is +1, because I think Django needs another stable release
> > right now. Fortunately, the trunk is stable (thank you!). Rob says
> > that it is good for a software project to have regularreleaseson a
> > half-year basis and I totally agree. This gives everyone the
> > opportunity to use a recent version of Django. Right now,
> > unfortunately, people with strong demands on stability, have to revert
> > to an outdated Django 0.96 or take a risk using Django trunk, which
> > feels like a choice between two wrongs.
>
> > Personally, I would be very happy to use a Django 1.0, with or without
> > newforms, just as it happens. And considering the posts, just having
> > this discussion already seems to motivate people into action! :)
>
> Quite a few Django projects are using the trunk version instead of the
> stable version for their addons, which is annoying for me running the
> stable version.  The problem is that Django has been so long without a
> release that the stable version is now a stale version - it reminds me
> of Debian taking so long with theirreleases.
>
> Every once in a while a release is needed for all the developers to
> group together on a common target, instead of being forced to pick
> between 0.96 and trunk.  I'm not looking for a 1.0 release, just
> something to keep developers going with a release until 1.0 is ready.
> At the moment people are forced to pick between stale and trunk, which
> ends up with more people picking trunk.
>
> The longer you leave it, more incompatible changes are going to be
> introduced between 0.96 and 1.0.  If a release is made between then it
> gives people a chance to update their sites to fix any problems with
> compatability, as well as a chance to play with some of the new
> features.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSoC: Effortless Model Testing

[Eric Walstad]

Hi Jason,
I'm not a Django dev and have nothing to do with GSOC but wanted to
make some comments on your proposal because I'm interested in it from
an end-user's perspective.

Jason Ledbetter wrote:
>...But I could drop
> the scripting idea and instead work off of a "batch options" object
> and keep everything pure python.
FWIW, this is the approach I would take, mostly because Python is what
I'm most comfortable with.


> I work for an insurance underwriting company and I've used Django very
> successfully to automate finances, policy issuance, our contact books,
> etc. It works great, but I'm working with what's probably an unusually
> complex set of data (compared to most users of Django). So my idea for
> the project comes from working in that environment.
I'm in a similar boat.  I write complex apps for the Energy Industry;
our apps have what I consider very complex data sets.  Testing them is
*hard*.


> You end up hobbling together scripts to generate valid but random data
> in order to populate a given set of instances. I have such a script
> here at work, to make sample insurance policies for our issuance
> system. It's hundreds of lines of ugly, hard-to-read, boilerplate
> code.
The test module for our finite state machine is about 900 lines long.
Ugly, boilerpplate, painful to update and/or customize for new test
cases.  That's just for the FSM.


> In situations of sufficient complexity, the boilerplate code becomes
> huge and you wear out the keys even *near* your copy and paste
> shortcuts. That inevitably leads to bugs and with a sufficiently large
> generating script, you fall into a "run it until it works" trudge. You
> get to step 15 of the generation process and find out you typed
> "underwriter" as "unserwriter" and you just wasted 25 minutes creating
> an incomplete set.
I feel this pain.


> From what I can see, most Django users don't have needs that complex.
> Right now Django isn't being used for things like insurance issuance
> very often.
but some of us DO...


So I have a serious interest in your GSOC testing work.  We are
planning a major refactoring of our code base this year and testing is
near the top of my priority list.  I'm interested in following your
progress, trying your code and reporting issues if you are open to
it.  If you start a mailing list or wiki or somesuch on your project,
please announce it on django-dev so I can follow along.

Best regards,

Eric.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANN: Upgrading code.djangoproject.com

[Eric Walstad]

Jacob Kaplan-Moss wrote:
> I'd also like to take this time to welcome Django's new official ticket 
> managers:
> 
>   * Chris Beaven (aka SmileyChris)
>   * Simon Greenhill
>   * Michael Radziej
>   * Gary Wilson
> 
> Although anyone can -- and is encouraged to -- help out keeping tickets 
> organized, these folks have volunteered to take ownership of the ticket 
> tracker in the long term.
> 
> Let's have a big virtual standing ovation for them!

Cheers Chris, Simon, Michael, Gary!
Thanks for your valuable time and help.

Best,

Eric.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Compacting SQL queries

[Eric Walstad]

Hawkeye wrote:
> ===
> (100 chars ~ 25% reduction)
...
> My second question is... if we can, is there any real value
> (specifically for very large sites)?

Our site isn't huge, but it's not small, either (~8M records).  Network 
bandwidth between the web and data servers is very near the bottom of my 
list of possible optimizations.  Maybe if I had to use 1200 baud packet 
radio between them ;)  Ah, the good ol' days.

73's
kc6ntp

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: magic-removal: plans/estimates for the trunk-merge?

[Eric Walstad]

On Monday 27 March 2006 15:22, binaryfeed wrote:
> gabor wrote:
> > is there a plan or a rough estimate about when the magic-removal
> > branch is going to be merged back to the trunk?
> >
> > this month?
> > next year?
>
> What's most frustrating about this thread is that no one has
> responded, really.  I mean, it'd be great to know if it was going
> to be a matter of days, weeks, or months.  Much as I search for it,
> this information seems to be impossible to find.

midi-chlorians tell me that there is a connection between this and the 
upcoming Django book.  But then again, my count is down there with 
Owen Lars.

I've-got-a-bad-feeling-about-this-ly yours...

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Caching Expression in Templates using a custom "Cache" Tag

[Eric Baker]

I wrote a custom tag that allows you to cache an expression in a
template.

I noticed, that my template was sending many duplicate queries to the
database because I was using a method in my model that used a foreign
key in a loop with many repeats.

I could have recoded the view to generate all the required data before
rendering the template, but chose to implement a caching mechanism for
the template instead.

There seem to be pros and cons to both approaches.

More details here: http://django.satilla.com/board/topic/2/

New Position at Naples Daily News using Django

[Eric Moritz]

One of the most respected and award-winning newspaper Web teams in the
world has moved to Florida and is looking for an experienced
server-side Web developer.

NDN Productions -- the online and new media publishing division of the
Naples Daily News -- is looking for a full-time Python programmer to
develop Internet-based applications that cross from computers to
mobile phones to iPods to Sony PSPs.

We strive for innovation and nimble development for sites that embrace
relational databases in ways they've rarely been used on the local
level coupled with broadband-centric multimedia content that all works
together in a platform-independent manner.

In other words, we strive to build the kinds of Web sites and related
offshoots that you wish were in your hometown.

We're big believers and contributors to the open-source community. Our
primary development platform is Python (mod_python) and PostgreSQL,
with a particular emphasis on using the Django infrastructure.

That being said, we believe a solid background in Web application
design is more important than knowledge of a particular language or
platform. If you're a smart cookie and it shows, we know that you'll
have no problems picking up the tools we use.

We embrace a highly creative, non-traditional work environment. We
love to work fast and have fun, with the time between having a great
idea and that idea being added to one of our sites being measured in
days, if not hours.

Our salary is competitive, though not crazy huge, and our benefits
package is sweet.

And because our agile and autonomous online team works under the
umbrella of one of the largest and most stabile diversified media
companies in the nation, you don't have to worry about your checks
ever bouncing. If you work with us, your mom and dad will be proud,
and your friends will be envious.

So, if you learn things quickly, want to hang out with cool people and
build amazing Web content, than this is the place for you.

We're an equal-opportunity employer. In fact, we even hire folks from Missouri.

So, contact Rob Curley at NDN Productions right now before one of your
buddies beats you to this great gig.

Rob Curley
Director of New Media
NDN Productions/The Naples Daily News
E >> [EMAIL PROTECTED]
P >> 239.435.3473

Re: Small report from Django/Rails meetup

[Eric Walstad]

On Tuesday 08 November 2005 08:35, Jacob Kaplan-Moss wrote:
> I think we need to bite our lips, suck it up, and release a 1.0  
> version.

+1

A "stable" release would make those who are trusting my judgement in 
choosing Django for a medium-large-ish project a little less nervous 
(me, too).