Re: Proposal: Tutorial Refresh

[Rob Hudson]

I, too, like the idea of a conference site.  It fills a void and
sounds useful for upcoming conferences.  I wasn't too crazy about the
blog idea, and was convinced away from the snippets idea.  So shall we
call it a conference site and move on?  :)

For a nice reference implementation, I'd like to point to the software
running the Open Source Bridge website.  It's developed in Ruby on
Rails and is hosted on Github:
http://github.com/igal/openconferenceware

I attended the Open Source Bridge conference and thought the website
was one of the most well done of any conference I've been to -- from
initial call for talks to attending and checking the schedule.

The website is here:
http://opensourcebridge.org/

If the intention is that this will be used for the DjangoCons, we
would need input from those that run DjangoCon.  For example, I really
liked the open submission process and the fact that the conference
took everyone's comments (which were private) into consideration when
picking the subset of talks.  But I can imagine that's not for
everyone.

Thanks,
Rob

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

[Bryan Veloso]

Also +1 to the idea of a conference site. I'm +0 on the prospect of
adding features like the ones on the Carsonified site for brevity's
sake. Definitely +1 to the prospect of seeing examples of unit testing
and caching. On a tangent, if there's any design work needed for said
site, I'll be happy to throw my hat in.

On Oct 9, 1:49 pm, Sean Brant  wrote:
> +1 Simon's idea of a conference site. Adding some features 
> likehttp://hello.carsonified.com/would be cool to have, though it might
> be to advance for this kind of tutorial.
>
> Sean
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

ANN: Critical security updates to Django 1.0 and Django 1.1

[James Bennett]

Today the Django project is issuing a set of releases to remedy a security
issue. This issue was disclosed publicly by a third party on a high-traffic
mailing list, and attempts have been made to exploit it against live Django
installations; as such, we are bypassing our normal policy for security
disclosure [1] and proceeding with immediate release of patches and updated
releases.

Full information is available on the Django project weblog:

http://www.djangoproject.com/weblog/2009/oct/09/security/

This issue has been fixed in Django's development trunk, and we've released
the following new versions of Django to address this issue:

* Django 1.1.1.

* Django 1.0.4.

These releases are available on our download page [2] and on PyPI [3].

This issue has seen active exploits in the wild. All users of affected version
of Django are strongly encouraged to upgrade of apply the appropriate patch
immediately.

As mentioned above, this issue was initially disclosed publicly on a
high-traffic mailing list. We'd like to remind our users that the correct
channel for security reports is to send them to .
This allows the development team time to develop a solution and coordinate
disclosure, both to the Django community as a whole and to the numerous third
parties who maintain and distribute packaged versions of Django.

When debating whether a particular issue impacts security, we ask that you err
on the side of caution and always contact ; we
will be more than happy to work with you in analyzing and assessing potential
security issues.

[1] http://docs.djangoproject.com/en/dev/internals/contributing/#id2
[2] http://www.djangoproject.com/download/
[3] http://pypi.python.org/pypi/Django

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Re: Proposal: Tutorial Refresh

[Sean Brant]

+1 Simon's idea of a conference site. Adding some features like
http://hello.carsonified.com/ would be cool to have, though it might
be to advance for this kind of tutorial.

Sean

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

[Simon Willison]

Put me down as a other +1 for a full site tutorial, especially one
that covers pip, virtualenv, unit testing and the like.

I have a suggestion for a site, too: How about the conference website
for the next DjangoCon? It's meant to be a community run conference so
the job needs to be done at some point, and building it as a community
tutorial project feels like it would be a nice fit.

A conference site is neat because it's a good example of a content
oriented site that isn't a blog, but can still take advantage of
generic views (and the admin, of course). It can be as simple or as
complicated as needed for the tutorial. We can even include API driven
features (recent tweets / photos from Flickr etc) which would be a
good way of demonstrating advanced concepts like caching.

Cheers,

Simon
--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Jani Tiainen]

Russell Keith-Magee kirjoitti:
> On Fri, Oct 9, 2009 at 11:22 PM, Jacob Kaplan-Moss  wrote:
>> On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson  wrote:
>>> * How do people feel about a tutorial that covers a complete site?
>> Well, in grand Django tradition, by suggesting this, you've
>> volunteered to be in charge :)
>>
>> But sign me up as an editor (language and code), at least, and I'll
>> try to help out by writing some sections, too.
> 
> Hi Rob,
> 
> I started to write a reply too, and then realized I was just writing
> "hell yeah" after each of Jacob's paragraphs. So I decided to stop.
> :-)
> 
> The only point I though I would elaborate on is the specific example
> for the tutorial. I agree with Jacob's comment that a pastebin is a
> bit of an esoteric example. There's also value in diversity - every
> extra example is one more sample site people can use as a point of
> reference. Having 2 pastebin examples floating around the community
> doesn't help much, but having a pastebin and something else adds some
> value.
> 
> My immediate reaction was that a blog engine is the natural example.
> It allows you to expose date-based generic views. You can use
> contrib.comments. You could show integration with any number of 3rd
> party apps. You could even demonstrate the transition to Pinax. The
> problem space is well known and well understood. Plus,
> write-your-own-blog-engine is a running joke in the Django community.
> :-)

Time of my learning I wondered this part - why always blogs. I don't 
want to write blog engine... :)

> That said, Jacob's bikeshed comment is also completely accurate. You
> build it, you get to choose. There's also something to be said for
> having a tutorial that doesn't duplicate the capabilities of any
> number of existing pluggable applications.

I can also lend my small hand. I've recently (last spring) gone through 
learning curve how to use (Geo)Django and how to get at least decent 
(IMO) system up and running.

I live in world of GIS. My projects are not traditional web apps, like 
blogs, pastebins. Personally I found a bit hard to find information that 
goes much beyond standard blog engine or simple forum. Also few 
surprises came along the path to where I am now.

And of course got some "why this wasn't mentioned in tutorial" moments.

-- 
Jani Tiainen

--~--~-~--~~~---~--~~
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: Patch: adding a msg parameter to assertContains and similar methods in the test client

[Christian Oudard]

First off, thank you all for responding and discussing this issue.

Responding to Russell's comments on the quality of the patch, I agree
that it needs better test coverage. I've uploaded an updated patch
which covers all exit points of assertFormError. The better tests
confirm that the original patch2 works as intended.

I think I might not have explained well enough what the intention of
the msg argument is. The argument is a literal string, which is not
formatted with any arguments. This is consistent with the behavior of
the standard library unittest functions.

For example, on line 124 of the original The syntax is like this:

def assertFormError(self, response, form, field, errors, msg=None):
...
self.fail(msg or "The field '%s' on form '%s' in context %d"
  " contains no errors" % (field, form, i))

Be aware of the difference here:

>>> msg = None
>>> msg or "foo%s" % "bar"
'foobar'
>>> msg = "test"
>>> msg or "foo%s" % "bar"
'test'
>>> (msg or "foo%s") % "bar"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting


As far as whether this is worth doing, the point of this patch is not
that the existing error messages are not descriptive enough. It is
that they cannot know the circumstances under which they will be
called in all cases. There may be very important bits of debugging
information that will never even be passed to the assert methods, or
be accessible from their scope. That is precisely the reason why the
methods like assertEquals in python have the extra msg parameter. They
could not have foreseen that the django library would use those msg
parameters in such creative ways to describe form errors and the like.
But the msg parameter handles it well, because it gives control to the
application programmer, who in general knows better than the library
developer what sort of error message he wants.

So everyone doesn't have to dig through the ticket messages, I'll
reprint the example I gave there.

This is a test that looks through a list of urls and checks that there
are no invalid template variables. Since the method assertNotContains
doesn't (and shouldn't) parrot back the url for the response, you
don't know what url failed, without using print statements or a
debugger.

class TemplateTestCase(ClientTestCase):
def testTemplateError(self):
urls = [
'/',
'/home/',
'/admin/',
# etcetera ...
]
for url in urls:
response = self.client.get(url, follow=True)
self.assertNotContains(
response,
settings.TEMPLATE_STRING_IF_INVALID,
msg='Found an invalid variable in url %s' % url)


On Oct 8, 12:12 pm, Tobias McNulty  wrote:
> On Thu, Oct 8, 2009 at 11:58 AM, Wes Winham  wrote:
> > This gives me a nice little summary. I know that there were more foo's
> > displayed on the page than there should have been.
>
> I second that.  The option to specify a quick message explaining what
> the failure means, for anyone who didn't write the test, can be the
> difference between a 2 minute fix and a half hour+ debugging session.
>
> Tobias
> --
> Tobias McNulty
> Caktus Consulting Group, LLC
> P.O. Box 1454
> Carrboro, NC 27510
> (919) 951-0052http://www.caktusgroup.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 1.2 roadmap and schedule

[Vinay Sajip]

On Oct 8, 6:44 pm, Jacob Kaplan-Moss  wrote:
> We're still gathering feature requests for 1.2 
> (seehttp://code.djangoproject.com/wiki/Version1.2Features), but we're
> going to work voting differently. Instead of categorizing features
> into "must-have / should-have / pony" categories, we're going to
> simply mark them high/medium/low priority, meaning:

I'd like to know about the app_label patch on #3591, which at one
early point in the 1.1 cycle was considered as a possibility for
inclusion. I'd like to add this in as a feature request, so should I
just go ahead and update the Wiki page (assuming I can)? If so, which
category should I add it in? I don't think it counts as a major
feature, but people have characterised it as that before (in terms of
impact rather than features).

The patch was last updated to work cleanly with r10759 in May 09 and
though I haven't kept it updated recently, I have no problems
committing to doing any further work  needed to get it into 1.2.

Regards,

Vinay Sajip
--~--~-~--~~~---~--~~
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

[Jacob Kaplan-Moss]

On Fri, Oct 9, 2009 at 4:33 AM, Simon Willison  wrote:
> For anyone interested in following this, I've just started a
> (currently experimental) branch on GitHub:
>
> http://github.com/simonw/django/tree/logging

One big question I have is about performance: have you done any a/b
testing against trunk to see how much adding logging -- especially
upon every SQL query -- impacts performance?

For me, at least, performance is going to be the critical factor. It's
clear that even a do-nothing logger will add some overhead. If we're
talking fractions of percents here, fine... but if there's a
measurable performance hit that's going to be a big problem, and it's
probably best to be tracking speed as we go along here.

Jacob

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

[Russell Keith-Magee]

On Fri, Oct 9, 2009 at 11:22 PM, Jacob Kaplan-Moss  wrote:
>
> On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson  wrote:
>> * How do people feel about a tutorial that covers a complete site?
>
> Well, in grand Django tradition, by suggesting this, you've
> volunteered to be in charge :)
>
> But sign me up as an editor (language and code), at least, and I'll
> try to help out by writing some sections, too.

Hi Rob,

I started to write a reply too, and then realized I was just writing
"hell yeah" after each of Jacob's paragraphs. So I decided to stop.
:-)

Put me down as willing to assist with reviewing and/editing, or just
general sanity checking.

The only point I though I would elaborate on is the specific example
for the tutorial. I agree with Jacob's comment that a pastebin is a
bit of an esoteric example. There's also value in diversity - every
extra example is one more sample site people can use as a point of
reference. Having 2 pastebin examples floating around the community
doesn't help much, but having a pastebin and something else adds some
value.

My immediate reaction was that a blog engine is the natural example.
It allows you to expose date-based generic views. You can use
contrib.comments. You could show integration with any number of 3rd
party apps. You could even demonstrate the transition to Pinax. The
problem space is well known and well understood. Plus,
write-your-own-blog-engine is a running joke in the Django community.
:-)

That said, Jacob's bikeshed comment is also completely accurate. You
build it, you get to choose. There's also something to be said for
having a tutorial that doesn't duplicate the capabilities of any
number of existing pluggable applications.

Russ %-)

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

[Alex Gaynor]

On Fri, Oct 9, 2009 at 6:12 AM, Luke Plant  wrote:
>
> On Friday 09 October 2009 10:33:28 Simon Willison wrote:
>> For anyone interested in following this, I've just started a
>> (currently experimental) branch on GitHub:
>>
>> http://github.com/simonw/django/tree/logging
>
> Is there some easy way to see the patch?  Preferably a link which will
> just show the diff between the latest of your branch and trunk, but
> failing that, a recipe of commands using git (for those of us who
> haven't bothered to learn git properly yet).
>
> Cheers,
>
> Luke
>
> --
> "We may not return the affection of those who like us, but we
> always respect their good judgement." -- Libbie Fudim
>
> Luke Plant || http://lukeplant.me.uk/
>
> >
>

Don't we wish it was possible for github to show a diff between two
branches... :(

Just venting'ly yours,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

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

[Jacob Kaplan-Moss]

Hi Rob --

First, thanks for taking this on. The tutorial indeed needs some good
lovin'; glad to see someone stepping up to the plate. I don't have a
huge amount of bandwidth these days, but I can commit to writing a
bit, and to editing anything you or anyone else writes.

On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson  wrote:
> * How do people feel about a tutorial that covers a complete site?

Like you, I think it's the best way to teach Django. A complete site
can show off more parts than just a small example project can.

> * How do people feel about that site being Django snippets?

Mmmm... that I'm not so sure about. Partly because this steps on
already trodden ground -- James' book (Practical Django Projects) goes
through djangosnippets as part of the book -- but also because it's a
somewhat insular example. That is, pastebins (of which djangosnippets
is a particular complex instance of) are the type of tool that really
only highly geeky folks use. Django's got a wider audience -- I know
Django users who are primarily journalists, designers, biologists, ...
-- and ideally the example we use should have relevance to a broad
cross-section of Django's audience.

Of course, all that said, I don't have a better suggestion other than
the tired personal blog example. So once again this is "if you build
the bikeshed you get to paint it" territory.

> * Comments on the proposed outline?  Are there any important steps
> missing?  Ordered logically? Feel free to add detail to any step.

Couple of things:

* This new tutorial absolutely should cover pip+virtualenv, most
likely right off the bat.
* We should de-emphasize the "apps live inside of projects" thing.
virtualenv gets the same effect we were shooting for there with much
less mess.
* Testing ought to be covered from the start -- I'd like to see every
little bit cover how to test it.

> * Do we cover things not in Django -- like model migrations, search,
> RESTful APIs -- using 3rd party Django apps?

I think the best idea would be cover how to find, install, and use
third-party apps, and then link to some popular ones. But leave the
actual how-tos to those authors.

> * Would it be possible to do this openly, with easy user comments,
> like the Django book?  Is that software available?

Heh. Sorta. The JS is okay and if you view source you should be able
to figure out how to find it; the backend code is a terrible one-off,
though.

However, I'm not totally sure that comments make a whole lot of sense
for documentation. We had comments on the docs for a while, back in
the day, and they just confused people. The comments were mostly the
type of questions people *should* be asking on django-users or in IRC.
Since nobody who could help them was reading the comments, they didn't
help at all. The other major open source projects with comments (PHP,
PostgreSQL) also seem to show similar trends. PHP's doc comments, in
particular, are a morass of bad advice.

The ideal, I think, would be a contextual *editing* tool: something
like the comment system, but allowing people to suggest changes that
editors could easily apply. That way people could fix typos, suggest
better wording, etc., but also not confuse the situation with bad
comments.

> Also, if we're going to pull this off we're going to need people to
> help in a variety of ways.  So I'm also curious who might be
> interested.  We'll need: authors to write some sections, reviewers to
> give feedback, editors to clean up text and bring uniformity to the
> whole thing, developers to make sure the software the tutorial is
> describing is coded using best practices and works, a handful of
> people to drive the process and foster community involvement, etc.

Well, in grand Django tradition, by suggesting this, you've
volunteered to be in charge :)

But sign me up as an editor (language and code), at least, and I'll
try to help out by writing some sections, too.

Jacob

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

Proposal: Tutorial Refresh

[Rob Hudson]

I'd like to propose the addition of a new tutorial that represents a
complete website, describing everything from start to finish.  This
would allow for many more topics to come into play -- things we all
deal with at some point in developing websites using Django.  This
would also allow for those topics to have a concrete central model and
not be hypothetical situations.  The end result should be source code
someone can checkout of a source control repository and run
themselves.  It would also be nice if the site being developed in the
tutorial were available and useful to the community as a whole.

To that end I'm also proposing that the site be http://www.djangosnippets.org/,
as long as James Bennett is ok with it.  The source code is already
available and under a BSD license.  The site is already well used and
important to the community.  The model is relatively simple (snippets)
with the possibility of a few 3rd party apps for things like ranking
of snippets, tagging, registration, Pygments, etc.  Django snippets
would also benefit from this process by getting an update to Django
1.0 (or newer).

I think an outline of the tutorial steps and what should be covered is
important to solidify at the outset.  That way if someone has a
particular interest in, say, caching, they could jump right in and
start fleshing out that step.  There are some dependencies on early
steps, of course.

Here's a very rough proposed outline that should be fleshed out more
and more detail added to each step on what topic areas to cover.  Much
of the current tutorial could be "ported" to the appropriate steps...

1. Creating a project - install, runserver, settings
2. Creating an app - app philosophy, INSTALLED_APPS
3. Creating models
4. Enabling the admin
5. Writing urls and views - generic views, custom views
6. Templates
7. Forms
8. Tests
9. 3rd party apps
10. Search
11. Feeds
12. Caching
13. APIs
14. i18n and l10n
15. Deployment

What I'd like to know is:
* How do people feel about a tutorial that covers a complete site?
* How do people feel about that site being Django snippets?
* Comments on the proposed outline?  Are there any important steps
missing?  Ordered logically? Feel free to add detail to any step.
* Do we cover things not in Django -- like model migrations, search,
RESTful APIs -- using 3rd party Django apps?
* Would it be possible to do this openly, with easy user comments,
like the Django book?  Is that software available?

Also, if we're going to pull this off we're going to need people to
help in a variety of ways.  So I'm also curious who might be
interested.  We'll need: authors to write some sections, reviewers to
give feedback, editors to clean up text and bring uniformity to the
whole thing, developers to make sure the software the tutorial is
describing is coded using best practices and works, a handful of
people to drive the process and foster community involvement, etc.

Feedback welcome,
Rob
--~--~-~--~~~---~--~~
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

[Simon Willison]

On Oct 9, 11:12 am, Luke Plant  wrote:
> >http://github.com/simonw/django/tree/logging
>
> Is there some easy way to see the patch?  Preferably a link which will
> just show the diff between the latest of your branch and trunk, but
> failing that, a recipe of commands using git (for those of us who
> haven't bothered to learn git properly yet).

Once things are a bit further along I'll start posting patches to the
ticket tracker, but for the moment you can see the changelog here:

http://github.com/simonw/django/commits/logging

There are only two relevant commits:

http://github.com/simonw/django/commit/b5227e1ac1d70b1f936ee69d6e347d8148df461e
http://github.com/simonw/django/commit/65ff505718538124ee2979fb60dfe1a37ca1b8bc

But since that means you have to patch together what's going on from
the two commits, I've pasted a full diff to trunk here:

http://dpaste.com/hold/104862/
--~--~-~--~~~---~--~~
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

[Luke Plant]

On Friday 09 October 2009 10:33:28 Simon Willison wrote:
> For anyone interested in following this, I've just started a
> (currently experimental) branch on GitHub:
> 
> http://github.com/simonw/django/tree/logging

Is there some easy way to see the patch?  Preferably a link which will 
just show the diff between the latest of your branch and trunk, but 
failing that, a recipe of commands using git (for those of us who 
haven't bothered to learn git properly yet).

Cheers,

Luke

-- 
"We may not return the affection of those who like us, but we 
always respect their good judgement." -- Libbie Fudim

Luke Plant || http://lukeplant.me.uk/

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

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

[Simon Willison]

For anyone interested in following this, I've just started a
(currently experimental) branch on GitHub:

http://github.com/simonw/django/tree/logging

So far I've added a 'django' logger which is silent by default, and
hooked up a new CursorLoggingWrapper to log all SQL statements from
the ORM to it. I've also modified the runserver command so you can use
the following to watch the execute SQL flow past on the console:

./manage.py runserver --loglevel=django.db.sql:info

None of the implementation code is intended to be production quality
yet (I'm just experimenting for the moment), but I'm very interested
in feedback on the approach.

Cheers,

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