Re: Proposal: Tutorial Refresh

[Russell Keith-Magee]

On Mon, Oct 12, 2009 at 7:15 AM, Zachary Voase
 wrote:
>
> On 11 Oct 2009, at 23:39, Joshua Russo wrote:
>
>> How about the possibility of an advanced tutorial, to highlight more
>> advanced features.
>
> That's pretty much what the Django Book is for.

No, it really isn't.

Firstly, The Django Book is an excellent resource, but it's not part
of the Django project itself. Django's documentation is Django's
documentation. Jacob and Adrian (and others) have written an excellent
book, and I have no objections to people suggesting that newcomers
should read that book, but it isn't part of Django's documentation.

Secondly, the Django Book isn't a tutorial. It's an excellent set of
explanatory notes of some advanced features, but it isn't a
walkthrough of a specific worked example.

I aspire to Django having the best documentation of any product out
there - open source or otherwise. Having a comprehensive tutorial is
part of that. Django's tutorial has said "more coming soon" for over 4
years, and there is a lot that could (nay, should) be explained in a
tutorial that we simply don't cover at the moment.

As for whether a complete rewrite is necessary - I'm happy to call
that a bikeshed. The current tutorial has served us well for four
years, but it is a simple example. If that simple example doesn't
provide enough scope for improvement, and Rob et al can come up with a
good replacement - one that starts equally simple, but can become
complex over time - I'm happy to entertain that proposal.

Rest assured, we're not going to replace a good tutorial with a bad
one. The tutorial won't be replaced until it is a worthy replacement
for what we already have.

Yours,
Russ Magee %-)

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

Re: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Russell Keith-Magee]

On Mon, Oct 12, 2009 at 4:56 AM, Vinay Sajip  wrote:
>
> On Oct 11, 4:31 pm, Russell Keith-Magee 
> wrote:

>> However, I can't recall the last time that someone asked the general
>> question of how to avoid a name collision between their two tagging
>> (or whatever) applications.
>
> I don't recall a lot of moaning about Django importing magic and the
> workarounds that have to be sometimes put in place.

Sorry? Django importing magic? "from app.models import MyModel"... is magic?

If you're referring to the historical importing scheme (i.e., the
version in 0.91, otherwise known as pre-magic-removal), then you need
to go back and look at the archives - there was plenty of confusion on
django-users about why models couldn't be imported literally, and why
model methods didn't always behave themselves, and so on.

> Simon's just
> posted about the fact that there's no good place to put execute-once
> code for setting things up, and I've not seen a lot of moaning about
> that. It doesn't mean it's not a problem - he's got a perfectly good
> point. It's just that people get on with working around it as they
> appear to have no easy alternative.

This theme isn't as common as User modification, but asking for a
'pre-config' signal does pop up every now and then.

> I'm not pushing a boulder up a steep slope for this to be fixed as
> I've scratched my own itch in this area. I'll leave it to others to
> raise the point if they feel the need to, but given your view I think
> you could just go ahead and mark #3591 as "wontfix" because that
> effectively appears to be the situation. There are, I think, numerous
> other tickets which have been closed as "wontfix" because "it's not a
> real problem".

Not at all. I have repeatedly acknowledged that this is a problem that
does exist - it's just not a  problem that many people have in
practice. Compare and contrast with issues on the v1.2 list -
multiple-db support is a problem that people have in practice. Logging
(or the lack thereof) is a problem that people have in practice.

Wontfix means we wont _ever_ fix the problem. That isn't true in this
case. If you (or anyone else) can come up with a good solution for the
problem, we'll fix it. However, in practice, you're going to need
feedback and input from the core to make this happen. I'm just warning
you (or whoever else tackles the problem) that it is going to be hard
to get the attention of the core to fix a problem that not many people
are having when there are plenty of other problems around.

Yours,
Russ Magee %-)

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

Re: Tutorial problem

[Wolf.Halton]

Thanks!
I commented out these lines
#urlpatterns = patterns('',
#(r'^admin/', include(admin.site.urls)),
#)
and will try the info you suggest

-Wolf

>
> If the admin worked fine and then broke during section three then you're
> likely hitting #11959, not #10050:
>
> http://code.djangoproject.com/ticket/11959
>
> That one hasn't been fixed yet but the ticket description and attached diff
> hopefully will make it clear to you how to fix things so admin works again
> as you continue working through the tutorial.
>
> Karen
--~--~-~--~~~---~--~~
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: Tutorial problem

[Karen Tracey]

On Sun, Oct 11, 2009 at 7:07 PM, Wolf.Halton  wrote:

>
> Ticket #10050 (closed: fixed)
>
> Opened 9 months ago
>
> Last modified 3 minutes ago
> Documentation bug in tutorial / admin manual? 'AdminSite' object has
> no attribute 'urls'
>
> Here is what I need to ask.  What trivial issue did I miss while doing
> the dev/tutorial?  presuming ubernostrum's response is accurate, then
> I have missed something trivial that I cannot find.  BTW, my admin
> pages worked great until I started page 3 and added content to
> urls.py   Either I believe there is still an error in the tutorial, or
> I made a trivial error that I need help with.  Help!
>

If the admin worked fine and then broke during section three then you're
likely hitting #11959, not #10050:

http://code.djangoproject.com/ticket/11959

That one hasn't been fixed yet but the ticket description and attached diff
hopefully will make it clear to you how to fix things so admin works again
as you continue working through the tutorial.

Karen

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

[Wolf.Halton]

I think this is a great idea.
I volunteer to test the tutorial.

Wolf

On Oct 9, 10:41 am, Rob Hudson  wrote:
> 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.
>
> 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
-~--~~~~--~~--~--~---

Tutorial problem

[Wolf.Halton]

Ticket #10050 (closed: fixed)

Opened 9 months ago

Last modified 3 minutes ago
Documentation bug in tutorial / admin manual? 'AdminSite' object has
no attribute 'urls'

Here is what I need to ask.  What trivial issue did I miss while doing
the dev/tutorial?  presuming ubernostrum's response is accurate, then
I have missed something trivial that I cannot find.  BTW, my admin
pages worked great until I started page 3 and added content to
urls.py   Either I believe there is still an error in the tutorial, or
I made a trivial error that I need help with.  Help!
---
10/11/09 17:46:18 changed by saphil  ¶

* status changed from closed to reopened.
* resolution deleted.

I just downloaded ver1.1 and am running the tutorial I got from the
link http://docs.djangoproject.com/en/dev/intro/tutorial03/#intro-tutorial03
I don't see the answer to the issue in the above comments, because I
am just getting into this. How early did the problem get into the
tutorial page. Everything seemed fine until I started page/part 3. I
can see this is a documentation issue, and probably really simple to
fix. I just don't know how. Help!
1.) does Ver 1.1 use an Earlier version's tutorial?
2.) has the tutorial linked through /dev/... not been updated

10/11/09 17:55:33 changed by ubernostrum ¶

* status changed from reopened to closed.
* resolution set to fixed.

The text of the tutorial at /dev/ is correct for 1.1 and trunk. The
text of the tutorial at /1.0/ is correct for 1.0. If you believe there
is still an error, bring it up on the django-developers mailing list
for discussion.

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

[Zachary Voase]

On 11 Oct 2009, at 23:39, Joshua Russo wrote:

> How about the possibility of an advanced tutorial, to highlight more  
> advanced features.

That's pretty much what the Django Book is for.

-- 
Zack

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

[Joshua Russo]

On Sun, Oct 11, 2009 at 7:40 PM, Rajeev J Sebastian <
rajeev.sebast...@gmail.com> wrote:

>
> On Sun, Oct 11, 2009 at 10:07 PM, Zachary Voase
>  wrote:
> >
> > On 11 Oct 2009, at 16:09, Alex Gaynor wrote:
> >
> >> I don't want to be overly negative, but in my view rewriting the
> >> tutorial would be a pointless waste of energy.  It has served us
> >> exceptionally well over the past 4 years, and none of the problems
> >> with it are fundamental, we'd be far better served by working to
> >> improve it, by adding more stages, than by rewriting it.  Further, I'd
> >> ague that the "staleness" of the tutorial is irrelevant, because the
> >> primary audience for the tutorial are precisely people who haven't
> >> seen it before.
> >>
> >> Alex
> >
> > I think I have to agree with Alex here. I’ve taught Django to a couple
> > of people in the past, and I found that the tutorial (as it is) worked
> > perfectly as an introduction to the concepts behind Django. After the
> > tutorial, the Django Book[1] is the next natural step, and it provides
> > a very solid grounding in pretty much everything, from development to
> > deployment. To round it all off, Eric Florenzano’s ‘Django from the
> > Ground Up’ showed them how to put what they had learned into practice.
> >
> > If there’s one thing *at all* that we should do, it’s add a chapter on
> > testing to the Django Book, and perhaps another section in the
> > tutorial devoted to it. But a comprehensive rewrite of the tutorial
> > seems completely unnecessary.
>
> +1
>
> I've trained 8 apprentices over the past 1-1/2 years. The existing
> django tutorial is invaluable since it can be done in about a day.


How about the possibility of an advanced tutorial, to highlight more
advanced 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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Vinay Sajip]

On Oct 11, 4:31 pm, Russell Keith-Magee 
wrote:
> If you can name a company that has produced more in-house Django
> applications than the number that is publicly available for download
> off the internet, I'll eat my hat. :-)

That isn't the right measure. I'm just saying that the total number of
applications out there is larger than the  total number of publicly-
available applications like "django-registration", "django-tagging"
etc. and it seems reasonable to posit that the larger the population,
the greater the likelihood of a clash.

> Obviously, it isn't as simple as that - there are _some_ ambiguous
> names out there in the wild. I'm just pointing out one of the reasons
> that name clashes aren't that big a problem is that basic
> Google-driven self interest acts as an incentive to keep the namespace
> relatively unambiguous.
[snip]
> If this were a common problem, you wouldn't need to prod django-users
> - it would already be a recurring theme. To pick on a different ticket
> of similar vintage: the question of how to replace/modify/change the
> User model (#3011) comes up regularly. Some people want to allow email
> addresses as the username; some want to replace firstname/lastname
> with a single "name" field; there are many other requests on the same
> theme. The fact that the question is repeatedly asked indicates that a
> problem of some form exists.
>
> However, I can't recall the last time that someone asked the general
> question of how to avoid a name collision between their two tagging
> (or whatever) applications.

I don't recall a lot of moaning about Django importing magic and the
workarounds that have to be sometimes put in place. Simon's just
posted about the fact that there's no good place to put execute-once
code for setting things up, and I've not seen a lot of moaning about
that. It doesn't mean it's not a problem - he's got a perfectly good
point. It's just that people get on with working around it as they
appear to have no easy alternative.

I'm not pushing a boulder up a steep slope for this to be fixed as
I've scratched my own itch in this area. I'll leave it to others to
raise the point if they feel the need to, but given your view I think
you could just go ahead and mark #3591 as "wontfix" because that
effectively appears to be the situation. There are, I think, numerous
other tickets which have been closed as "wontfix" because "it's not a
real problem".

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

[Sean Bleier]

>
>
> > 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))
>
> would become:
>
> prefix = msg and "%s: " % msg or ""
> self.fail("%sThe field '%s' on form '%s' in context %d"
>  " contains no errors" % (prefix, field, form, i))
>
> This preserves the best of both worlds - a rich failure message, plus
> the ability to add user-specific context to help identify the source
> of the problem in the test suite. This does differ from the behavior
> of the assert* functions in the standard library, but hopefully in a
> way that makes sense under the circumstances. Opinions?
>
> Yours,
> Russ Magee %-)
>
>
I like Russ's prefix idea.  I believe Christian's concern is that the
django's error messages do not give enough context for the programmer when
debuging.  Adding the prefix allows programmers to add that context without
blindly overridding the error message that django throws.

Karen is right about the name of msg if it is going to serve as a prefix to
the msg given to Python's assert* methods.  Something like msg_prefix or
prefix would be more appropriate IMO

Using Christian's example, I might change it to:

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_prefix='Error in url %s' % url)

This way for the two cases in which assertNotContains can fail, you can have
errors messages like:
"Error in url /home/: Couldn't retrieve page: Response code was 404
(expected 200)"
or
"Error in url /home/: Response should not contain
'TEMPLATE_STRING_IF_INVALID"

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

[Rajeev J Sebastian]

On Sun, Oct 11, 2009 at 10:07 PM, Zachary Voase
 wrote:
>
> On 11 Oct 2009, at 16:09, Alex Gaynor wrote:
>
>> I don't want to be overly negative, but in my view rewriting the
>> tutorial would be a pointless waste of energy.  It has served us
>> exceptionally well over the past 4 years, and none of the problems
>> with it are fundamental, we'd be far better served by working to
>> improve it, by adding more stages, than by rewriting it.  Further, I'd
>> ague that the "staleness" of the tutorial is irrelevant, because the
>> primary audience for the tutorial are precisely people who haven't
>> seen it before.
>>
>> Alex
>
> I think I have to agree with Alex here. I’ve taught Django to a couple
> of people in the past, and I found that the tutorial (as it is) worked
> perfectly as an introduction to the concepts behind Django. After the
> tutorial, the Django Book[1] is the next natural step, and it provides
> a very solid grounding in pretty much everything, from development to
> deployment. To round it all off, Eric Florenzano’s ‘Django from the
> Ground Up’ showed them how to put what they had learned into practice.
>
> If there’s one thing *at all* that we should do, it’s add a chapter on
> testing to the Django Book, and perhaps another section in the
> tutorial devoted to it. But a comprehensive rewrite of the tutorial
> seems completely unnecessary.

+1

I've trained 8 apprentices over the past 1-1/2 years. The existing
django tutorial is invaluable since it can be done in about a day.

Regards
Rajeev J Sebastian

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

[Vinay Sajip]

On Oct 11, 7:57 pm, Hanne Moa  wrote:
> On Sun, Oct 11, 2009 at 04:42, Simon Willison  wrote:
> > I'm keen to receive as much feedback on the implementation as possible.
>
> It is perfectly possible to set up logging in such a way that all the
> logs for several programs wind up in the same file, or there are
> duplicate entries. The first happens/happened if/when several programs
> used the same interpreter. The second is user error. Been there been
> stumped by both. Users need to be protected from both, somehow, but
> how... Might be that a standard way for doing it in Django will
> suffice for case 2. Will a warning/docs be needed for case 1?

"Logs for several programs wind up in the same file": this could
happen if multiple programs (scripts) use a FileHandler for file
"foo.log" with mode "a" (append). Then the logs will end up in the
same file because that's what's been asked for. I'm not sure what you
mean when you say "several programs used the same interpreter" - as
normally you have one Python interpreter per process. So if you are
talking about one invocation of a Python executable, then I'm not sure
what you mean by "programs", other than the executable running several
scripts in turn, in a way such as:

for scriptname in scriptnames:
mod = __import__(scriptname)
mod.main()

In that case, since the Python logging system is per-process, it will
be there across these multiple invocations and behave as if all of the
scriptnames main() calls are part of the single process - which they
are.

Typically, duplicate messages are caused when multiple handlers are
added to loggers. For example if one handler was added to both "foo"
and the root logger, and if the "foo" logger propagates to its parent
(the default setting) then you will get messages twice - once from
"foo"'s handlers and once from the root's handlers. This often happens
because people wrongly conflate loggers and handlers and think there
has to be a one-to-one correspondence between them. Nowadays you only
occasionally see questions on comp.lang.python about duplicate
messages, so I'm not sure if this still causes confusion.

I'm not sure what you can do to protect users from this, it's similar
to how it's hard in Django to have code which is guaranteed to execute
once and only once (see Simon's separate thread about this), but in
logging it's easy to avoid. You just have to document how things work
as best you can, and go from there.

> When I first used the logging-library (2002?) I had a problem in
> threaded programs, some exceptions were swallowed that shouldn't have
> been, leading to rather mysterious behaviour. The exception-hierarchy
> have been changed (a couple of times ;) ) since then so it might no
> longer be an issue but I'd sleep better if there was tests for this
> too. Vinay?

What exception hierarchy are you talking about? Logging's policy on
swallowing exceptions has been consistent throughout, and is that
exceptions caused in logging (say, format string doesn't tie up with
arguments) are always swallowed because you don't want an application
to crash because of a logging error or misconfiguration. Exceptions
such as SystemExit and KeyboardInterrupt should never be swallowed.
Some other exceptions are handled by handleError() methods of handlers
which sometimes retry (in the case of sockets) and at other times
check the logging.raiseExceptions flag. If this is set to False (as it
should be in production) then exceptions during handling are always
swallowed - but these are exceptions due to the logging itself rather
than exceptions in the application.

Logging should be safe in threaded programs because threading.RLocks
are used to synchronize access to module shared state and I/O between
multiple threads. I don't know of any threading bugs - and remember,
use of threading just by itself can sometimes lead to "mysterious
behaviour" because it's easy to miss race conditions, deadlocks etc.

One problem with writing tests for threading is that a threaded
program can follow a whole bunch of execution paths, all of which are
correct, because of OS scheduling being affected by other stuff
running on the machine (e.g. backup jobs, network monitoring) which is
outside your control. All of which means that having a defined outcome
to compare against becomes problematic.

Of course if you have any specific thread-safety issue relating to
logging, then please raise an issue on the Python bug tracker and
attach a small script which illustrates the problem.

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 

Re: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Hanne Moa]

On Sun, Oct 11, 2009 at 01:46, Russell Keith-Magee
 wrote:
>
> On Sun, Oct 11, 2009 at 6:19 AM, Hanne Moa  wrote:
>>
>> On Sat, Oct 10, 2009 at 13:51, Russell Keith-Magee
>>  wrote:
>>> Looking at #3591 in particular - another big part of the problem is
>>> that the ticket tries to solve a theoretical problem that, in
>>> practice, doesn't really exist - that of namespace collisions in
>>> applications.
>>
>> That's funny, has happended three times to me this far.
>
> If I may ask - which apps (or app names) caused the collision?

The really annoying hair-raising one had a generic name (not blog :)
), mark or pick or something, and was pulled in as a suggested
dependency by aptitude and put in a zipped egg. I don't like those
either, breaks find/locate and studying sys.path  :)


HM

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

[Hanne Moa]

On Sun, Oct 11, 2009 at 04:42, Simon Willison  wrote:
> I'm keen to receive as much feedback on the implementation as possible.

It is perfectly possible to set up logging in such a way that all the
logs for several programs wind up in the same file, or there are
duplicate entries. The first happens/happened if/when several programs
used the same interpreter. The second is user error. Been there been
stumped by both. Users need to be protected from both, somehow, but
how... Might be that a standard way for doing it in Django will
suffice for case 2. Will a warning/docs be needed for case 1?

When I first used the logging-library (2002?) I had a problem in
threaded programs, some exceptions were swallowed that shouldn't have
been, leading to rather mysterious behaviour. The exception-hierarchy
have been changed (a couple of times ;) ) since then so it might no
longer be an issue but I'd sleep better if there was tests for this
too. Vinay?


HM

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

[Zachary Voase]

On 11 Oct 2009, at 16:09, Alex Gaynor wrote:

> I don't want to be overly negative, but in my view rewriting the
> tutorial would be a pointless waste of energy.  It has served us
> exceptionally well over the past 4 years, and none of the problems
> with it are fundamental, we'd be far better served by working to
> improve it, by adding more stages, than by rewriting it.  Further, I'd
> ague that the "staleness" of the tutorial is irrelevant, because the
> primary audience for the tutorial are precisely people who haven't
> seen it before.
>
> Alex

I think I have to agree with Alex here. I’ve taught Django to a couple  
of people in the past, and I found that the tutorial (as it is) worked  
perfectly as an introduction to the concepts behind Django. After the  
tutorial, the Django Book[1] is the next natural step, and it provides  
a very solid grounding in pretty much everything, from development to  
deployment. To round it all off, Eric Florenzano’s ‘Django from the  
Ground Up’ showed them how to put what they had learned into practice.

If there’s one thing *at all* that we should do, it’s add a chapter on  
testing to the Django Book, and perhaps another section in the  
tutorial devoted to it. But a comprehensive rewrite of the tutorial  
seems completely unnecessary.

-- 
Zack

[1]: http://djangobook.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: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Russell Keith-Magee]

On Sun, Oct 11, 2009 at 10:42 PM, Vinay Sajip  wrote:
>
> On Oct 11, 9:52 am, Russell Keith-Magee 
> wrote:
>> On Sun, Oct 11, 2009 at 3:23 PM, Vinay Sajip  wrote:
>>
>> This is true, but again, the distinction between theoretical and
>> practical problem emerges. The set of mainstream apps in the wild is
>> much larger than the set of in house apps controlled by any
>> company/group - so if the problem doesn't exist in practice for apps
>> in the wild, the potential for the same problem to emerge in the
>> smaller subset of in-house apps isn't that large.
>
> Fair enough, though I don't see how you could know the number of in-
> house apps written by companies. I don't want to labour the point,
> either.

If you can name a company that has produced more in-house Django
applications than the number that is publicly available for download
off the internet, I'll eat my hat. :-)

>> I was referring to the fact that if your name is unique, it's easy for
>> people to find it. Google isn't good at disambiguating, so it's in the
>> interests of every project owner to choose a name that is unique.
>
> Yes, but I don't see the relevance to the disambiguation issue.

You're proposing a solution to a name clash problem. If there is no
ambiguity in names, then there _is_ no name clash problem.

Obviously, it isn't as simple as that - there are _some_ ambiguous
names out there in the wild. I'm just pointing out one of the reasons
that name clashes aren't that big a problem is that basic
Google-driven self interest acts as an incentive to keep the namespace
relatively unambiguous.

>> So we're talking about a hypothetical situation with two applications
>> named tagging, which *both* need to be used in a single project, where
>> *neither* application can have their name changed (either because they
>> are both in the wild, and the self interest or because in-house
>> policies won't allow a rename).
>>
>> Again - I don't deny that there is a problem in theory. I'm just not
>> convinced that it is a problem in practice.
>
> I acknowledged at the outset that it was a hypothetical example, and
> that I personally don't have that problem any more, though I did at
> the time (way back when). I also didn't open that ticket originally,
> so someone else at least would have come across the issue. But if
> you're saying that since it's all open source and users can always
> rename their modules (and references to them) to work around the
> problem, then I suppose it's up to the community to say whether that's
> a problem or not. And should this be posted on django-users, since
> perhaps this might have bitten people who don't follow this list? I
> presume the django-users readership is quite a bit larger than django-
> developers.

If this were a common problem, you wouldn't need to prod django-users
- it would already be a recurring theme. To pick on a different ticket
of similar vintage: the question of how to replace/modify/change the
User model (#3011) comes up regularly. Some people want to allow email
addresses as the username; some want to replace firstname/lastname
with a single "name" field; there are many other requests on the same
theme. The fact that the question is repeatedly asked indicates that a
problem of some form exists.

However, I can't recall the last time that someone asked the general
question of how to avoid a name collision between their two tagging
(or whatever) applications.

I want to reinforce that I'm not morally opposed to this proposal or
anything like that. If you want to pursue it, please do. I just want
to give you fair warning that it's going to be hard to get any real
movement on this issue unless you can get the involvement of someone
from the core, and that is going to be hard to do unless you can prove
that you have a real problem that needs to be solved. Personally, I
think we have bigger fish to fry before we deal with hypothetical
problems.

Yours
Russ Magee %-)

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

Re: Proposal: Tutorial Refresh

[Alex Gaynor]

On Sun, Oct 11, 2009 at 7:24 AM, andybak  wrote:
>
> Another thing that might be useful to cover in the tutorial is the
> 'building for re-usability' ideas that have devloped via Pinax et al.
>
> Maybe at least one part of the functionality developed in the tutorial
> should be in the form an app intended to be used across projects.
> Combine this with incorporating existing 3rd party apps in the project
> and we've captured a very powerful lesson about Django.
>
> (edit - this is already hinted at in some of the other comments but
> I'll still post this for the extra emphasis)
> >
>

I don't want to be overly negative, but in my view rewriting the
tutorial would be a pointless waste of energy.  It has served us
exceptionally well over the past 4 years, and none of the problems
with it are fundamental, we'd be far better served by working to
improve it, by adding more stages, than by rewriting it.  Further, I'd
ague that the "staleness" of the tutorial is irrelevant, because the
primary audience for the tutorial are precisely people who haven't
seen it before.

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: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Vinay Sajip]

On Oct 11, 9:52 am, Russell Keith-Magee 
wrote:
> On Sun, Oct 11, 2009 at 3:23 PM, Vinay Sajip  wrote:
>
> This is true, but again, the distinction between theoretical and
> practical problem emerges. The set of mainstream apps in the wild is
> much larger than the set of in house apps controlled by any
> company/group - so if the problem doesn't exist in practice for apps
> in the wild, the potential for the same problem to emerge in the
> smaller subset of in-house apps isn't that large.

Fair enough, though I don't see how you could know the number of in-
house apps written by companies. I don't want to labour the point,
either.

> On top of that, companies have the ability to rename their in house
> resources; they don't have the ability to force apps in the wild to
> change their name.
>
> I was referring to the fact that if your name is unique, it's easy for
> people to find it. Google isn't good at disambiguating, so it's in the
> interests of every project owner to choose a name that is unique.

Yes, but I don't see the relevance to the disambiguation issue.

> As a project maintainer, it's in your interest to choose a unique
> name, and this enlightened self interest has been sufficient to ensure
> a namespace that has been conflict free in my experience.

That's the name of the package as a whole, there's no reason why
'django-mingus' necessarily have to a package name that ends in
'mingus'.

> So we're talking about a hypothetical situation with two applications
> named tagging, which *both* need to be used in a single project, where
> *neither* application can have their name changed (either because they
> are both in the wild, and the self interest or because in-house
> policies won't allow a rename).
>
> Again - I don't deny that there is a problem in theory. I'm just not
> convinced that it is a problem in practice.

I acknowledged at the outset that it was a hypothetical example, and
that I personally don't have that problem any more, though I did at
the time (way back when). I also didn't open that ticket originally,
so someone else at least would have come across the issue. But if
you're saying that since it's all open source and users can always
rename their modules (and references to them) to work around the
problem, then I suppose it's up to the community to say whether that's
a problem or not. And should this be posted on django-users, since
perhaps this might have bitten people who don't follow this list? I
presume the django-users readership is quite a bit larger than django-
developers.

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: Tutorial Refresh

[andybak]

Another thing that might be useful to cover in the tutorial is the
'building for re-usability' ideas that have devloped via Pinax et al.

Maybe at least one part of the functionality developed in the tutorial
should be in the form an app intended to be used across projects.
Combine this with incorporating existing 3rd party apps in the project
and we've captured a very powerful lesson about Django.

(edit - this is already hinted at in some of the other comments but
I'll still post this for the extra emphasis)
--~--~-~--~~~---~--~~
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: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Russell Keith-Magee]

On Sun, Oct 11, 2009 at 3:23 PM, Vinay Sajip  wrote:
>
> On Oct 11, 12:46 am, Russell Keith-Magee 
> wrote:
>> If I may ask - which apps (or app names) caused the collision? Off the
>> top of my head, I can't think of any especially mainstream application
>
> Considering just "mainstream" applications would appear to discount
> any applications which are developed in-house and not available to the
> wider public. In development shops with numerous development teams,
> this could happen and lead to clashes with apps from other teams as
> well as when incorporating "mainstream" applications. In such cases
> people would just fork, working round the limitation, rather than make
> a fuss about it.

This is true, but again, the distinction between theoretical and
practical problem emerges. The set of mainstream apps in the wild is
much larger than the set of in house apps controlled by any
company/group - so if the problem doesn't exist in practice for apps
in the wild, the potential for the same problem to emerge in the
smaller subset of in-house apps isn't that large.

On top of that, companies have the ability to rename their in house
resources; they don't have the ability to force apps in the wild to
change their name.

>> that share a package name. In my experience, the fact that having a
>> unique name makes it easier to get Google juice has been enough to
>> keep the namespace clean.
>
> It's the last part of the package name that clashes, as that's used as
> the app label, db prefix etc., and I don't see how you'd expect to get
> any Google juice from the last part of the name which is typically a
> rather prosaic word. I would have thought the Google juice came from
> the whole name e.g. "django-registration" or "django-tagging".

I was referring to the fact that if your name is unique, it's easy for
people to find it. Google isn't good at disambiguating, so it's in the
interests of every project owner to choose a name that is unique.

Case in point - try looking for web page about Sphinx. You will find,
in no particular order:
 * The Python documentation engine
 * The full text index server
 * Information on Greek/Egyptian mythology.

On the other hand, it's easy to find details on django-mingus.

As a project maintainer, it's in your interest to choose a unique
name, and this enlightened self interest has been sufficient to ensure
a namespace that has been conflict free in my experience.

> So, if my hypothetical site had the concept of tagging in a sense
> other than tag clouds (for example, livestock tagging) and I was using
> an app whose package name ended in 'tagging', and if I later wanted to
> use "django-tagging" in the UI, I'd have to edit one of the 'tagging's
> to change the last part of the package name. This particular example
> is not a real-world one, and obviously if I'd known that I was going
> to use "django-tagging" at the outset and I was writing the other app
> I could have named it to end with "tags". But like isn't always like
> that :-(

So we're talking about a hypothetical situation with two applications
named tagging, which *both* need to be used in a single project, where
*neither* application can have their name changed (either because they
are both in the wild, and the self interest or because in-house
policies won't allow a rename).

Again - I don't deny that there is a problem in theory. I'm just not
convinced that it is a problem in practice.

Yours,
Russ Magee %-)

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

Re: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

[Vinay Sajip]

On Oct 11, 12:46 am, Russell Keith-Magee 
wrote:
> If I may ask - which apps (or app names) caused the collision? Off the
> top of my head, I can't think of any especially mainstream application

Considering just "mainstream" applications would appear to discount
any applications which are developed in-house and not available to the
wider public. In development shops with numerous development teams,
this could happen and lead to clashes with apps from other teams as
well as when incorporating "mainstream" applications. In such cases
people would just fork, working round the limitation, rather than make
a fuss about it.

> that share a package name. In my experience, the fact that having a
> unique name makes it easier to get Google juice has been enough to
> keep the namespace clean.

It's the last part of the package name that clashes, as that's used as
the app label, db prefix etc., and I don't see how you'd expect to get
any Google juice from the last part of the name which is typically a
rather prosaic word. I would have thought the Google juice came from
the whole name e.g. "django-registration" or "django-tagging".

So, if my hypothetical site had the concept of tagging in a sense
other than tag clouds (for example, livestock tagging) and I was using
an app whose package name ended in 'tagging', and if I later wanted to
use "django-tagging" in the UI, I'd have to edit one of the 'tagging's
to change the last part of the package name. This particular example
is not a real-world one, and obviously if I'd known that I was going
to use "django-tagging" at the outset and I was writing the other app
I could have named it to end with "tags". But like isn't always like
that :-(

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