Re: Imports in the tutorial

This topic came up in discussion today and Peter pointed us here. Kudos to Andrew for showing initiative. Short of new tutorials, I think the best service we could do for the (beginner) community is to at least call out a sidebar that provides some brief context around whether or not to namespace

Re: Imports in the tutorial

On 12/06/2010 01:03, Russell Keith-Magee wrote: What - very very quickly? I don't see the problem :-) Well, that wasn't quite the quality I was going for, but you never know. Problem is there's several things that could go in a part 5 (in addition to all of those there currently),

Re: Imports in the tutorial

On Saturday, June 12, 2010, Andrew Godwin wrote: > > > On 11/06/2010 17:38, Russell Keith-Magee wrote: > > You're not missing anything specific -- it's really just a matter of > time. Good documentation take time to write; doubly so for good > tutorials. > > The issue you

Re: Imports in the tutorial

On 11/06/2010 17:38, Russell Keith-Magee wrote: You're not missing anything specific -- it's really just a matter of time. Good documentation take time to write; doubly so for good tutorials. The issue you raise - that the current tutorial is exclusively "app inside project" has been raised

Re: Imports in the tutorial

On Fri, Jun 11, 2010 at 1:21 AM, Andrew Godwin <and...@aeracode.org> wrote: > Hi all, > > I noticed today that the tutorial still does imports like "from > mysite.polls.models import Poll", and URLs like "(r'^polls/$', > 'mysite.polls.views.index')"

RE: Imports in the tutorial

Of Andrew Godwin Sent: Friday, June 11, 2010 9:11 AM To: django-developers@googlegroups.com Subject: Re: Imports in the tutorial Compared to the alternative, and the unlikeliness of this scenario, I really feel it's the best move, unless we try to teach new users about virtualenv, pip, dependency

Re: Imports in the tutorial

On 11/06/10 17:00, Peter Baumgartner wrote: > Why do your two sites need to share the same python path? Virtualenv > solves this problem quite gracefully. > They don't have to, but bear in mind that: a) The tutorial is aimed at people new to Django, and often new to Python. Virtualenv isn't

Re: Imports in the tutorial

On Fri, Jun 11, 2010 at 9:16 AM, Andrew Godwin wrote: > > > On 11/06/2010 03:28, Peter Baumgartner wrote: >> >> In my experience, almost every project has domain-specific >> applications that don't get reused. If you have a reusable app, you >> bundle it separately (like

Re: Imports in the tutorial

On Fri, Jun 11, 2010 at 10:16 AM, Andrew Godwin wrote: >> I agree that it is confusing that it will work either way, but I'd >> argue in favor of using the project name everywhere. It is explicit >> instead of mucking around with the Python path behind the scenes. >> > >

Re: Imports in the tutorial

On 11/06/2010 03:28, Peter Baumgartner wrote: In my experience, almost every project has domain-specific applications that don't get reused. If you have a reusable app, you bundle it separately (like South). I entirely agree, but there's also a lot of domain-specific apps people make

Re: Imports in the tutorial

On Thu, Jun 10, 2010 at 11:21 AM, Andrew Godwin <and...@aeracode.org> wrote: > Hi all, > > I noticed today that the tutorial still does imports like "from > mysite.polls.models import Poll", and URLs like "(r'^polls/$', > 'mysite.polls.views.index')". >

Re: Imports in the tutorial

"I agree, and while we're at it also change the settings.py template to just point to urls instead of project_name.urls" Indeed, always the first thing I change when I start a project... Having the project_name there means you are including the directory above your project in the python path in

Re: Imports in the tutorial

I agree, and while we're at it also change the settings.py template to just point to urls instead of project_name.urls On Jun 10, 7:21 pm, Andrew Godwin <and...@aeracode.org> wrote: > Hi all, > > I noticed today that the tutorial still does imports like "from > mysite.p

Imports in the tutorial

Hi all, I noticed today that the tutorial still does imports like "from mysite.polls.models import Poll", and URLs like "(r'^polls/$', 'mysite.polls.views.index')". At least in the places and projects I've worked with, the standard has been not to use the project name a