Re: extra() and values()

[Steve Holden]

Nicolas Lara wrote:
> The ticket is in the tracking sistem: #7256. I have claimed it, but am
> not planning to start working on it until I'm done with aggregation
> (or maybe in EuroPython's sprint), so if anybody bits me to it, it
> would be great.
>
>   
In that case you would be better off leaving it unclaimed until you are 
ready to work on it. Moset people look for unassigned tickets when they 
have bug fixing time, to avoid repetition of work.

regards
 Steve




--~--~-~--~~~---~--~~
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: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Steve Holden]

Russell Keith-Magee wrote:
> On Thu, Jun 19, 2008 at 9:04 PM, Peter Melvyn <[EMAIL PROTECTED]> wrote:
>   
>> On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>>
>> 
>>>  (2) provide a way to manually disable and re-enable integrity checks. If
>>>  someone with more MySQL-fu than me knows how to do either of these
>>>   
>> It should work:
>>
>> SET FOREIGN_KEY_CHECKS = 0;
>> 
>
> Yes - the ticket for this problem (#3615) already has a patch that
> uses this technique.
>
> However, I was under the impression that this has the effect of
> disabling, not just deferring key checks - that is, if you disable
> checks, load bad data, then re-enable checks, no errors will be
> raised. We don't want to be responsible for breaking the referential
> integrity of a database, so this isn't a viable solution.
>
> If I've misunderstood the behaviour of SET FOREIGN_KEY_CHECKS, or you
> have any other suggestions, let me know - I'd very much like to put
> this bug behind us.
>   
Well I guess the obvious (time consuming, painful) way would be to 
validate the semantic integrity from Django in the back end. That could, 
if automated, get horrendously time-consuming for even quite small 
changes to the database.

Would there be any way to analyze which constraints could be affected by 
the SQL executed while checks were disabled, so automated checks could 
be limited to those?

Otherwise I'd guess you end up saying "Tough, MySQL is currently 
broken/less capable". Maybe we could talk to Ted Leung about that?

regards
 Steve


--~--~-~--~~~---~--~~
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: Spam detection

[Steve Holden]

Jacob Kaplan-Moss wrote:
> On Thu, Jun 26, 2008 at 1:06 PM, Andreas Klöckner
> <[EMAIL PROTECTED]> wrote:
>   
>> I tried to submit this bug, but it wouldn't let me--it thought I'm a spammer.
>> 
>
> Quoting from the ticket submission page:
>
> "If you're getting rejected by the spam filter, we apologize! The best
> way to avoid that is to register for an account and make sure you're
> logged in."
>
>   
OK, a 500 error isn't really appropriate anyway, surely: the submission 
is being rejected due to lack of authentication, presumably this is 
supposed to mislead spammers?

Why not begin the message with:

"Did you register an account and log in before submitting your issue? 
Non-registration is the most common cause of this error. Please click 
here to register an account before submitting this issue."

Or something similar.

regards
 Steve
> The version on that page even has links.
>
> Help me out here: how can I make it more obvious? You missed that;
> others often do to. Can you share with me some insights on how you
> missed it?
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Community representation

[Steve Holden]

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: Spam detection

[Steve Holden]

Rob van der Linde wrote:
> I see there is now a link to the registration page when you go to file a
> ticket, but why not put it on page where the login/settings links are
> (just underneath the search box). This is where it is by default in Trac
> and people might expect to see it there, like I did myself initially.

... and why not have it say "Your post *will* be rejected as spam unless 
you are registered and logged in"? At the moment it sounds like you 
*might* get away with an unregistered posting.

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: Community representation, or, #django user "Magus-" needs to go far away

[Steve Holden]

Eric wrote:
> Well, you can teach someone to fish without telling them to "get an
> f'n fishing pole".
>
>   
"Give a man a fish and he will eat for a day. Teach him how to fish and 
for the rest of his life he will bore you with stories about the one 
that got away".

regards
 Steve


--~--~-~--~~~---~--~~
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: Declarative syntax for widgets in ModelForm

[Steve Holden]

Ivan Sagalaev wrote:
> Hi, everyone!
> 
> I was recently refactoring some old code to use a ModelForm and was 
> stuck at an issue that we don't have a simple way to say "this form has 
> these fields from a model but with other widgets".
> 
> For example I have an Article model that I want to edit in a form:
> 
>  class ArticleForm(ModelForm):
>  class Meta:
>  model = Article
>  fields = ['author', 'text']
> 
> This is nice! But now I want to use a bit larger textarea for 'text' and 
> want specify it with attrs={'cols': 80, 'rows': 20}. Currently I have 
> two options:
> 
> 1. Redeclare entire field:
> 
>  class ArticleForm(ModelForm):
>  text = CharField(
>  u'Text',
>  is_required=True,
>  widget=Textarea(...))
> 
>  class Meta:
>  model = Article
>  fields = ['author']
> 
> The problem is that along with a widget I have to repeat other 
> attributes of a field: type, label, required-ness, help_text etc... 
> Which is bad because it's, ahem, "non DRY" :-). It's also looks a bit 
> strange because now fields are declared in two different ways.
> 
> 2. Fix widget in __init__:
> 
>  class ArticleForm(ModelForm):
>  class Meta:
>  model = Article
>  fields = ['author', 'text']
> 
>  def __init__(self, *args, **kwargs):
>  super(ArticleForm, self).__init__(*args, **kwargs)
>  self.fields['text'].widget = Textarea(...)
> 
> Here the problem is that it has enough boilerplate code to be, shall we 
> say, not beautiful. And also it defeats nice declarative nature of a 
> ModelForm.
> 
> In other words the problem of ModelForm is that we have very usefule 
> separation between fields and widgets but we cannot declare them separately.
> 
> 
> ## Proposal
> 
> To fix this I was thinking along the lines of:
> 
>  class ArticleForm(ModelForm):
>  class Meta:
>  model = Article
>  fields = ['author', 'text']
>  widgets = {
>  'text': Textarea(...),
>  }
> 
> I know it can be done now with formfieldcallback but it doesn't look 
> nearly as readable because you have to write an imperative logic 
> comparing field names.
> 
> Sound sane?
> 
What's CSS for?

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: ~Q broken?

[Steve Holden]

Malcolm Tredinnick wrote:
> 
> On Wed, 2008-07-16 at 10:12 -0700, serbaut wrote:
>> Consider the following equivalent queries based on the weblog model
>> from the documentation:
>>
>> Blog.objects.filter(name="myblog").exclude(entry__body_text__contains="blah
>> blah")
>> Blog.objects.filter(Q(name="myblog") &
>> QNot(Q(entry__body_text__contains="blah blah"))) # 0.96
>> Blog.objects.filter(Q(name="myblog") &
>> ~Q(entry__body_text__contains="blah blah")) # development  version
>>
>> In 0.96 the evaluated SQL is (edited for readability):
>>
>> SELECT blog_blog.id,blog_blog.name,blog_blog.tagline
>> FROM blog_blog
>> INNER JOIN blog_entry AS blog_blog__entry ON blog_blog.id =
>> blog_blog__entry.blog_id
>> WHERE blog_blog.name = "myblog"
>> AND (NOT (blog_blog__entry.body_text LIKE "%blah blah%"))
>>
>> while in trunk (r7982) it is
>>
>> SELECT blog_blog.id, blog_blog.name, blog_blog.tagline
>> FROM blog_blog
>> WHERE blog_blog.name = "myblog"
>> AND (NOT (blog_blog.id IN (SELECT blog_entry.blog_id FROM blog_entry
>> WHERE blog_entry.body_text LIKE "%blah blah%")))
>>
>> The trunk version will perform a subquery over all blog entries which
>> will have a very negative performance impact.
>>
>> Lets say "myblog" has 10 entries in a database with 10,000,000
>> entries, the first SQL will only examine the 10 entries (assuming
>> decent query planner) while the latter will scan the whole database. A
>> join with blog_blog.id is missing from the subquery or it needs to be
>> rewritten to the 0.96 form. I understand that the code tries to handle
>> the generic case but this practical case has to work too.
> 
> The important difference, that trumps everything else, is that the 0.96
> version gives the wrong answer! It isn't a case of less or more
> efficient -- it's the difference between correct and incorrect.
> 
> The query you described asks to exclude all blog entries containing a
> particular tag. Now consider a blog entry that has two entries. One is
> the entry you're interested in excluding and the second entry is
> something else. Because that blog has an row in the m2m join table that
> does not match the entry you are excluding, that blog will be included
> (incorrectly) in the result set. This was a very big bug in 0.96 and
> impossible to work around in that code.
> 
> There is no way to write that particular exclusion correctly without
> using nested subqueries unless you have some arbitrary constraint like
> only one tag per blog entry (in which case a many-to-many field is the
> wrong choice).
> 
> Remember that the query you are writing here is something that returns
> (and filters) Blog objects. It's not for excluding individual Entry
> objects. It uses the presence or absence of an Entry to filter the
> Blogs.
> 
> Your case is particularly pessimal, since it isn't going to be helped by
> index matches in most cases. For more natural uses, such as excluding by
> pk values, or whole-field matches, adding appropriate index comparisons
> makes the inner query very efficient if it becomes a performance issue
> in production environments.
> 
Note that there's nothing wring in the general case with nested 
subqueries. The problem arises with what are called "correlated 
subqueries", where an element of the rows from the outer query is used 
in the sub-query.

In other words, given an employee table where each employee has a 
manager, it's quite fast to work out who earns more than a specific 
employee:

SELECT * FROM employee WHERE salary > (
 SELECT salary FROM employee WHERE ID=1234)

The subquery returns a result that's invariant over the rows of the 
outer query, and most SQL implementations will only perform it the once. 
It's quite a different story if you want to find out who earns more than 
their manager, however:

SELECT * FROM employee AS sub WHERE salary > (
 SELECT salary FROM employee AS mgr WHERE sub.salary > mgr.salary)

In such cases the SQL optimizer usually has little choice but to repeat 
the subquery for each row in the outer query, which can get a little 
expensive.

Then later said:

> The problem is that the filter you specified was not returning the
> correct answer in 0.96. You're asking that Django returns an incorrect
> result to make your code faster. It's possible to give incorrect results
> very fast, but it's not something we want to support.

Which made me laugh :-)

Sorry if this is preaching to the choir: sometimes people assume that 
*all* nested 

Re: Is URL template tag's syntax going to change?

[Steve Holden]

Johannes Dollinger wrote:
[...]
> Of course that's subjective, everything is.
> 
Really? That's a bit sweeping.

"The atomic number of hydrogen is 1" (IMHO?).

regards
  Steve
Who just felt like picking this particular nit. Sorry.
-- 
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: Session expiration times

[Steve Holden]

TP wrote:

> I recently ran into what I thought was counter-intuitive session
> expiration behavior. See ticket http://code.djangoproject.com/ticket/8452
> for the details.
> 
> I don't mean to dig up topics that have been long debated, but I also
> wonder if these semantics make sense?
> 
> If I log into a site and only happen to read from my session, my
> session will log out in SESSION_COOKIE_AGE seconds (or whatever
> set_expiry says). However, if I happen to do actions that cause writes
> to my session then my session will expire in some hard-to-determine
> point in the future. How to explain to a user when they will be logged
> out -- X seconds after their last session write? I wrote the app and
> I'm not even sure when the session is written to due to third party
> libraries etc.
> 
> Further, for security reasons it seems like it's a good policy for
> Django to ship with the default behavior for every session to
> automatically expire SESSION_COOKIE_AGE seconds after the session was
> created no matter what. If the app wants to push out the expiration
> time every time the user is active, they can call set_expiry
> explicitly. But I guess that's just one person's opinion.
> 
> Alternatively, for consistency, Django could update the expiry age
> whenever the session is _read_ or written. Then the docs could simply
> say the expiry age is updated whenever the session is used which is
> very simple to understand: anytime someone comes back to the site
> their session expiration time will renew. If they don't come back
> within the expiration time, their session expires.

SESSION_SAVE_EVERY_REQUEST is by far the most sensible option, and the
default behavior for every other web framework I've used. Interaction of
any kind with the server should be taken as an indication that the
session user wants the session to remain alive.

At least it's documented, though ...

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

DjangoCon

[Steve Holden]

Well, since I can't make the conference I hope that everyone who *does*
get there has a great time!

regards
 Steve


--~--~-~--~~~---~--~~
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: Mentoring students

[Steve Holden]

Chris De Vries wrote:
> Hi,
> 
> My name is Chris De Vries and I am involved with the IEEE student
> branch at the Queensland University of Technology in Brisbane,
> Australia [1]. I am organizing a program that encourages students to
> become involved with open source. I am looking for projects that are
> interested in taking on students. The branch will be running an
> information session and I am hoping to list some projects that are
> willing to mentor students. Is Django interested?
> 
> Thanks,
> Chris De Vries
> 
> [1] http://ewh.ieee.org/sb/queensland/qut/
> 
Chris:

Any project that was involved with the Google Summer of Code might well
be interested in mentoring student projects.

You might also want to ask on the django-users list (if you haven't
already), as there may be applications of Django that meet your
requirements.

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: I want a pony: Django Cheeseshop

[Steve Holden]

mrts wrote:
> On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
>   
>> 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 Python community).
>> 
>
> Although I don't know anything about the talk, that's exactly what I
> wanted to say: as Django and Python communities are different,
> overflooding CheeseShop with Django apps does not serve Python
> community at all.
>
> And I never had re-implementing setuptools in mind -- what I meant was
> to extend and build upon setuptools and easy_install.
>   
I don't see why Django can't be just as much a part of the Python
community as, say, Zope, who frequently distribute code through PyPi. I
don't see the advantage of fragmenting the infrastructure. That's what
it's there for - supporting Python users.

regards
 Steve
[PSF chairman]


--~--~-~--~~~---~--~~
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: Distributed RCS

[Steve Holden]

ew ways of
> doing things, and re-examining philosophies that are followed. That is
> how I became a linux user, and a Python programmer. That is why I
> started using Django. I was investigating a new way of doing things, and
> found that Django had something good to offer. Here I'm just presenting
> an alternate philosophy, and hoping for discussion to take place. I
> believe that embracing the distributed RCS philosophy will help nurture
> the development of Django in the long run.
> 
> Basically, what I'm really trying to say is that there is no pony yet.
> There is only a really big pig with a fake pony tail tied onto it,
> wearing a saddle. Very ugly. Very Scary. Close your eyes. Little girls
> are screaming.
> 
Well, speaking as an old fart, and something of a stick-in-the-mud, I am
interested in using the best possible version control system, but even
more interested in something that's easy to use.

When you consider attracting new members to the development community,
ease of use of the development infrastructure is important.

I've heard good things about Mercurial, Bazaar and git, but I get the
impression that git is sometimes difficult to drive. Overall the idea of
a distributed version control system is great. But will I be able to
drive it without getting myself in a mess?

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: I want a pony: Distributed RCS

[Steve Holden]

Jacob Kaplan-Moss wrote:
[...]
> 
> So, again, sorry about being a dick!
> 
Well at least you're a dick with a proper sense of proportion and the
ability to apologize when necessary. Thanks for setting a good example.

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: I want a pony: Django Cheeseshop

[Steve Holden]

Martin Diers wrote:
> On Sep 13, 2008, at 7:23 PM, Russell Keith-Magee wrote:
>
>   
>> On Sun, Sep 14, 2008 at 6:35 AM, Martin Diers <[EMAIL PROTECTED]> wrote:
>> 
>>> The answer is community packaging guidelines. Somebody needs to write
>>> or adapt an existing doc on how to package django apps using existing
>>> Python tools (which are excellent already), how to name them, etc.
>>>   
>> Somebody really is a great guy. He does a lot of great work for the
>> community, doesn't he :-)
>>
>> If you think this document is required, why not write it? Don't wait
>> for permission - just write it!
>>
>> Of course, if you actually sat down to write this document, you would
>> rapidly discover why it hasn't been written - the questions you need
>> to answer haven't got canonical answers yet. Are you familiar with the
>> Django Hotclub? This project started out to answer exactly these
>> questions, and they still don't have canonical answers. Pinax is an
>> attempt to discover best practices through empirical means, but they
>> don't have a complete set of answers.
>>
>> Yours,
>> Russ Magee %-)
>> 
>
>
> Look, that's exactly my point. Authorship aside, just throwing up a  
> platform for submitting packages accomplishes nothing without  
> packaging guidelines. Besides, we already have that. It's called  
> Google Code.
>
> Pinax provides a model perhaps for the manner of packaging a project,  
> but as a whole is more cathedral than bazar. Is it the answer? I don't  
> know.
>
> I don't know because I am not qualified to write such guidelines. I  
> have not been using Django long enough to understand all its parts  
> well enough, nor to propose how others should work. But I sure as hell  
> don't want to see yet another repository canonized before the footwork  
> is complete. Thus here's my vote: No.
>   
Just to return to the original theme, I've been in touch with Richard
Jones, Pypi's (the Cheeseshop's) maintainer. He points out that there's
already a "Frameworks :: Django" Trove discriminator available, and
suggests that if Django developers have a need to change the code
(though I am not sure why they would) that too would be possible.

The only proviso to that is that the existing web APIs used by distutils
and setuptools need to be retained. If they weren't, of course, it would
kind of nullify the point of using PyPi in the first place.

regards
 Steve


--~--~-~--~~~---~--~~
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: Install over old level produces mutant [solved!]

[Steve Holden]

Karen Tracey wrote:
> We've had at least three people run into a problem (#9090) after
> installing 1.0 over an old level.  Now, we do document that before
> installing you should remove any old level.  But I find the results
> when you don't rather odd. It's not just old files renamed/deleted in
> the new level that wind up being 'leftover' in the site-packages
> directory. Rather, some files that exist in both levels, and changed
> between the two, are not updated by install.  So you wind up with a
> mixture of 0.96.x and 1.0 level files, which is pretty confusing and
> subject to odd failures.
>
> Does anyone know if there is something we could do to prevent this
> situation?  I'm not very familiar with Python installation
> procedures.  It seems like it would be better, though, if our
> installer flat-out refused to install over a pre-existing installation
> or offered to delete the pre-existing install before continuing with
> the new install.  What's the norm for Python packages?
>
> Karen
>

I suspect what's happening is that the install keeps the distribution
dates on the .py files, but that the people who see the problems have
installed (or at least recompiled) the older versions more recently, so
the interpreter doesn't require an overwrite of the 0.96 files.

I've just done an install of 1.0 on my Python 2.6 alpha2 distribution
and I see, for example, that .../django/views/static.py is dated
12/17/2007. In this case there wasn't a previous installation, so I
can't verify that the compilation won't take place if there's an
existing .pyc file. However I *did* verify that a clean re-install
(after deletion of the appropriate build subdirectories) did *not*
change the creation time of the .py file.

So the answer is to put another step in the build process that touches
all files before bundling them up for distribution. Obviously this is
best done outside the version control system.

regards
 Steve


--~--~-~--~~~---~--~~
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: Install over old level produces mutant [solved!]

[Steve Holden]

Steve Holden wrote:
[...]
> I've just done an install of 1.0 on my Python 2.6 alpha2 distribution
> and I see, for example, that .../django/views/static.py is dated
> 12/17/2007. In this case there wasn't a previous installation, so I
> can't verify that the compilation won't take place if there's an
> existing .pyc file. However I *did* verify that a clean re-install
> (after deletion of the appropriate build subdirectories) did *not*
> change the creation time of the .py file.

Sorry, that should have been ".pyc file".
> 
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: Install over old level produces mutant

[Steve Holden]

Fredrik Lundh wrote:
> Karen Tracey wrote:
>
>   
>> We've had at least three people run into a problem (#9090) after 
>> installing 1.0 over an old level.  Now, we do document that before 
>> installing you should remove any old level.  But I find the results when 
>> you don't rather odd. It's not just old files renamed/deleted in the new 
>> level that wind up being 'leftover' in the site-packages directory. 
>> Rather, some files that exist in both levels, and changed between the 
>> two, are not updated by install.  So you wind up with a mixture of 
>> 0.96.x and 1.0 level files, which is pretty confusing and subject to odd 
>> failures.
>> 
>
> does that apply to PY files, or is it just that you may have PYC files 
> from 0.96.x but PY files from 1.0?   (Python only looks at the timestamp 
> when deciding whether to recompile a PY file, so if your PYC files for 
> 0.96.x were created later than the corresponding 1.0 file, Python will 
> pick up the wrong file).
>
> is the installer you're referring to here "setup.py", or something else?
>
>   
See ticket #9112 for a purported explanation.

regards
 Steve


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

[Steve Holden]

Malcolm Tredinnick wrote:
> On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
>   
> [...]
>> setuptools is a necessary evil for the agile developer who frequently
>> tracks updates for the bits he relies upon. Hopefully it will be
>> improved (the clamor around it is ever-ongoing), but unless we want to
>> do it ourselves, we have to accept the state of things.
>> 
>
> Wow. You just said we should entirely ditch security because it isn't
> convenient. That's exactly the attitude that has made Microsoft the
> laughing stock of the professional IT community for the last 15 years.
>
>   
Which, sadly, hasn't affected either their profits or their market
dominance.
> If my original mail had said "nobody should ever use setup tools" or
> anything like that, you reply might be valid. Go back and read it. I
> said "optional", not "forbidden". There are multiple audiences here. If
> Django ever had a hard dependency on setuptools for using third-party
> packages it would make it very difficult for system administrators to
> use Django because of the large level of security uncertainty and extra
> overhead that comes with using it. So, again, it's fine for people who
> want to to use setuptools and virtualenv and buildout and eggs and
> rinky-dinky-tool-of-choice. People use things knowing that there are
> always trade-offs and compromises. It's bad once policy starts being
> enforced on something that is simply unusable in certain environments.
>   
Yes, anyone looking for "the one true way" is doomed to disappointment.
You only have to review recent correspondence on python-dev to realize
that no one person is aware of all the requirements of the various
platforms for which modern applications must be packaged.

I don't much like the pejorative implication of matching
"rinky-dinky-tool-of-choice" with the other listed alternative, however.
Personally I think virtualenv is a good solution to a tricky problem.

The thing that bugs me most of all is Python developers who assume that
the answer to all Python distribution problems is the assumption that a
single Python installation can support all required applications. In
this day and age it's quite practical to look at distributing the
required interpreter as a component of your application or framework.
There is no reason why your Python program and mine need have any
components in common, and increasingly less reason to enforce this
requirement to save disk space.

Having said which, Django and other frameworks don't have that luxury:
if I'm running Django on 2.4 then every app my Django installation
supports also has to run on 2.4.

regards
 Steve


--~--~-~--~~~---~--~~
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: [Fwd: Documentation: Google-foo lost]

[Steve Holden]

Don Spaulding wrote:
>
>
> On Tue, Sep 16, 2008 at 2:20 PM, Don Spaulding
> <[EMAIL PROTECTED] > wrote:
>
>
> Hope it's useful!
>
>
>
> and of course it isn't.  I forgot my lambdas.  Doh!
>
That's a great start. I noticed that many Google links are to fragments,
and wondered if we could do some sort of recognition on them. It turned
out to be interesting, as I was hadn't realised the documentation
doesn't implement fragment references in the expected way.

I pulled down the current documentation and the 0.96 stuff with
websucker - I think it broke before it got quite all the old stuff, but
the majority is present. The work I have done would really best be done
on the final version of the pre-1.0 documentation before it was
converted to the new organization, but I couldn't find that. So far I've
only looked at the section headings, which can be located easily as .

There are 119 sections like
general-questions
genericsitemap
specialities-of-django-translation
definitive-urls
creating-models
installation-questions
template-inheritance
overriding-default-model-methods
less-code and
serialization-formats

which don't seem to appear (as sections) in the new documentation. So
it's goodbye to them unless they appear as other structures in the new
documentation.

There are apparently 678 newly-minted sections like
module-django.forms.fields
using-generic-relations-as-an-inline
inherited-models
onetoonefield
extra-methods-on-managers-when-used-in-a-foreignkey-context
post-delete
inlinemodeladmin-objects
module-django.test
module-django.http and
the-file-object

that never appeared (as sections) in the old documentation, so we don't
need to worry about them unless they appeared as tags on some other type
of object.

The *good* news is that there appear to be 789 sections that can be
redirected (hopefully with 301s, so Google and pals will pick up the new
locations), of which a few examples are:

Tag requesting-features
was: ./contributing/index.html
now: dev/internals/contributing/index.html
Tag font-sizes
was: ./admin_css/index.html
now: dev/obsolete/admin-css/index.html
Tag relationships
was: ./model-api/index.html
now: dev/topics/db/models/index.html
Tag phone2numeric
was: ./templates/index.html
now: dev/ref/templates/builtins/index.html
Tag pprint
was: ./templates/index.html
now: dev/ref/templates/builtins/index.html
Tag restarting-the-spawned-server
was: ./fastcgi/index.html
now: dev/howto/deployment/fastcgi/index.html
Tag basics
was: ./templates_python/index.html
now: dev/ref/templates/api/index.html
Tag how-to-add-change-and-delete-redirects
was: ./redirects/index.html
now: dev/ref/contrib/redirects/index.html
Tag seeing-which-settings-you-ve-changed
was: ./settings/index.html
now: dev/topics/settings/index.html
Tag custom-default-settings
was: ./settings/index.html
now: dev/topics/settings/index.html

Sorry that the old and new references aren't strictly comparable: this
has been a spare time project in a rather busy week. I'm sure it's
fairly obvious where they can be found.

The question is: is it worth continuing this web-scraping and analysis
and potentially extending it to other reference mechanisms I am unaware
of? I don't know whether the current redirection will eventually cause
the web search engines to throw away the old references, but it would be
nice to be able to move them forward if possible.

regards
 Steve




--~--~-~--~~~---~--~~
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: [Fwd: Documentation: Google-foo lost]

[Steve Holden]

Jacob Kaplan-Moss wrote:
> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>   
>> The question is: is it worth continuing this web-scraping and analysis
>> and potentially extending it to other reference mechanisms I am unaware
>> of? I don't know whether the current redirection will eventually cause
>> the web search engines to throw away the old references, but it would be
>> nice to be able to move them forward if possible.
>> 
>
> Yes, this is extremely helpful. I'd like to get some better redirects
> in place ASAP, so if you can work with your script to give me a
> complete list I can throw 'em up. I've done a couple of things for
> anyone who can help:
>
> * I've temporarily removed the global redirect; it's just confusing.
> We'll replace it with more granular redirects a bit later.
>
> * I've added a page to the wiki for redirects:
> http://code.djangoproject.com/wiki/DocumentationRedirects
>
> * I'll start writing some code to help with the redirects. We'll need
> a bit of javascript to help with the fragment redirects since the web
> server doesn't get fragments; I'll get that done.
>
> Monday morning I'm going to replace the redirects with whatever's at
> the wiki page.
>   
Great. What else do I need to look for besides the section-class divs? I
can put a little more time in to this over the weekend. Documentation
needs at least as much love as code ...

regards
 Steve


--~--~-~--~~~---~--~~
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: [Fwd: Documentation: Google-foo lost]

[Steve Holden]

Jacob Kaplan-Moss wrote:
> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>   
>> The question is: is it worth continuing this web-scraping and analysis
>> and potentially extending it to other reference mechanisms I am unaware
>> of? I don't know whether the current redirection will eventually cause
>> the web search engines to throw away the old references, but it would be
>> nice to be able to move them forward if possible.
>> 
>
> Yes, this is extremely helpful. I'd like to get some better redirects
> in place ASAP, so if you can work with your script to give me a
> complete list I can throw 'em up. I've done a couple of things for
> anyone who can help:
>
> * I've temporarily removed the global redirect; it's just confusing.
> We'll replace it with more granular redirects a bit later.
>
> * I've added a page to the wiki for redirects:
> http://code.djangoproject.com/wiki/DocumentationRedirects
>
> * I'll start writing some code to help with the redirects. We'll need
> a bit of javascript to help with the fragment redirects since the web
> server doesn't get fragments; I'll get that done.
>
> Monday morning I'm going to replace the redirects with whatever's at
> the wiki page.
>
>   
I re-did the work starting with the pre-refactor docs instead of the
0.96 ones, and I've added almost 1,000 redirects to the Wiki page. These
are all based on  id's, let me know if there's anything else I
should look at before Monday.

regards
 Steve


--~--~-~--~~~---~--~~
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: [Fwd: Documentation: Google-foo lost]

[Steve Holden]

Steve Holden wrote:
> Jacob Kaplan-Moss wrote:
>> On Fri, Sep 19, 2008 at 2:19 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>>   
>>> The question is: is it worth continuing this web-scraping and analysis
>>> and potentially extending it to other reference mechanisms I am unaware
>>> of? I don't know whether the current redirection will eventually cause
>>> the web search engines to throw away the old references, but it would be
>>> nice to be able to move them forward if possible.
>>> 
>> Yes, this is extremely helpful. I'd like to get some better redirects
>> in place ASAP, so if you can work with your script to give me a
>> complete list I can throw 'em up. I've done a couple of things for
>> anyone who can help:
>>
>> * I've temporarily removed the global redirect; it's just confusing.
>> We'll replace it with more granular redirects a bit later.
>>
>> * I've added a page to the wiki for redirects:
>> http://code.djangoproject.com/wiki/DocumentationRedirects
>>
>> * I'll start writing some code to help with the redirects. We'll need
>> a bit of javascript to help with the fragment redirects since the web
>> server doesn't get fragments; I'll get that done.
>>
>> Monday morning I'm going to replace the redirects with whatever's at
>> the wiki page.
>>
>>   
> I re-did the work starting with the pre-refactor docs instead of the
> 0.96 ones, and I've added almost 1,000 redirects to the Wiki page. These
> are all based on  id's, let me know if there's anything else I
> should look at before Monday.
> 
It looks as though the global redirect may have been there long enough
to start Google replacing some of the original content now, I'm sorry to
say. I just searched for

  django http redirect

and the first hit was the root page of docs.djangoproject.com :(
-- 
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: Denormalisation, magic, and is it really that useful?

[Steve Holden]

This appears to be a proposal to re-implement triggers inside Django.

I can see there are benefits if the underlying DB platform won't support
triggers, but wouldn't triggers be the preferred solution when they're
available? That way there is no chance that changes can be made outside
the scope of the denormalization, and hence no need to recompute the
denormalized values.

regards
 Steve

Andrew Godwin wrote:
> David Cramer wrote:
>   
>> If you're not doing denormalization in your database, most likely
>> you're doing something wrong. I really like the approach that is
>> offered here.
>>
>> For me, personally, it would be great if this could accept callables
>> as well. So you could store the username, like so, or you could store
>> a choices field like:
>>
>> field = models.IntegerField(choices=CHOICES)
>> denorm = models.DenormField('self', 'get_field_display') # which
>> would rock if it was .field.display ;)
>>
>> You could also make it somehow accept querysets or something similar
>> for things like count(). I see a lot of possibilities and am a bit
>> disappointed I didn't come up with something this easy for my use-
>> cases.
>>   
>> 
>
> The key is making sure you can listen for changes on whatever's at the 
> other end of your denormalisation. With my current snippet, it listens 
> for a save on the model the foreignkey points to, then checks for the 
> right ID; if we start accepting random querysets, then there has to be a 
> way to resolve that back to conditions the signal listener can understand.
>
> Still, with an 
> AggregateField(Sandwiches.filter(filling="cheese").count()) it's still 
> possible to work out that you want to listen on the Sandwiches model, 
> and you could then fall back to re-running the count on every Sandwich 
> save, even if it ends up not having a cheese filling.
>
> So, I think the best approach would be one to replicate fields (like my 
> current DenormField; perhaps call it CopyField or something) and one to 
> cache aggregates (an AggregateField, like above).
>
> Simon Willison wrote:
>   
>> Just so it's on the record, I'd like any denormalisation tools in
>> Django to include a mechanism for re-syncronizing them should
>> something go awry (like direct updates being applied to the database
>> without keeping the denormalised fields in sync). This mechanism could
>> then be exposed as a ./manage.py command which could be called
>> periodically to verify and fix any incorrect data.
>> 
> Yes, this I very much agree with. The reason you always layer this stuff 
> on top of a pre-normalised database is because you can then rebuild the 
> data after playing with it externally.
>
> Doing so shouldn't be too much of a problem; have a management command 
> that loads the models, and then just executes the update method on each 
> of the denormalisationalish fields.
>
> Justin's idea of lazy updating is interesting, and probably quite doable 
> (as well as what most people will want by default on aggregate queries).
>
> I'm also hoping any kind of aggregate denormalisation will work with any 
> future extended aggregate support, but if the field just takes a normal 
> QuerySet, that might Just Work™.
>
> Andrew
>
>
> >
>
>   



--~--~-~--~~~---~--~~
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: Python 2.6 abstract base classes

[Steve Holden]

Malcolm Tredinnick wrote:
> On Thu, 2008-10-02 at 10:32 -0400, Marty Alchin wrote:
>   
>> Looking over the new things in Python 2.6, I wonder if there are plans
>> to inherit from any of the new abstract base classes in Django. It
>> looks (to me) like it could be backwards-compatible, using an import
>> like so:
>>
>> try:
>> from collections import Sequence
>> except ImportError:
>> # Fallback for Python 2.5
>> Sequence = type('Sequence', (object,), {})
>>
>> Django obviously works just fine without these at the moment, so
>> there's no pressing need to do so, but if they catch on and 2.6+
>> libraries start checking for them, it might be beneficial if some of
>> our custom types, like QuerySets, inherited the appropriate classes.
>> 
>
> How about we wait until that looks like maybe happening, then? Python
> 2.6 is approximately 43 seconds old and there isn't a lot of real-world
> experience with the traps and benefits of using this approach yet.
> Hopefully people writing 2.6 code won't be deliberately making it
> difficult for code that is portable across more than the "latest
> hotness" version to function and we can avoid having to add four lines
> of relatively confusing line-noise to our import statements.
>
> Python code should be readable. The above code fragment fails that test
> and whilst we have some similar code for other backwards compatibility
> reasons, the existing cases are requirements. This one is optional, so
> I'd much rather avoid it for now.
>   
+1

Trendy might be superficially appealing, but I personally felt 2.6 would
have been just as useful without the ABC backport.

regards
 Steve


--~--~-~--~~~---~--~~
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: GET requests should not alter data?

[Steve Holden]

Amit Upadhyay wrote:
> On Wed, Oct 15, 2008 at 5:17 PM, Ivan Sagalaev
> <[EMAIL PROTECTED]> wrote:
>   
>> Amit Upadhyay wrote:
>> 
>>> This is not about specs or what is allowed, rather what is there in
>>> actual django. And about implementation goals for django. It is
>>> possible to have a django(core+contrib apps shipped with django) with
>>> only SELECT queries in response for GET request. So far I have
>>> identified two places and their work arounds. Are there more? They
>>> should be avoided, and if not possible documented.
>>>   
>> For example you can't implement OpenID consumer without altering
>> application state on GET (actually logging a user in happens upon HTTP
>> redirect).
>> 
>
> Its necessary given openid spec I guess. Can it be worked around by
> not splitting GET/POST for urls starting with /openid/? Can a GET on
>   

That's a pretty fragile test. What happens if I decide to start my URLs
with /Openid/, or /authenticate/openid/, or ... ?
> any request, thanks to some middleware maybe, write or writes are
> limited to one of few URLs? Such questions are not easy to answer
> offhand for someone who is using the app, and should be  can go
> somewhere in readme.scaling.txt/less frequently asked question for the
> app may be. Along with other resources, files/directories etc that may
> be used by openid consumer, from the point of view of scaling.
>   
While I can see the generic desirability of GET requests not making
database writes there are always going to be exceptions. Let's not
pursue this as a purist goal, but rather for the sound pragmatic reasons
that have already been elucidated.

regards
 Steve


--~--~-~--~~~---~--~~
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: Determining the active urlpattern for navigational templates

[Steve Holden]

Jesse Young wrote:
> I'm guessing it's somewhat common (as usual, I think it's common
> because I do it) to put several navigational links in a template that
> is included from several other templates, e.g.:
>
> Page 1
> Page 2
> ...
> Page N
>
> But also, it's helpful to indicate where the user currently is in the
> navigational hierarchy, e.g.:
>
> Page 1
> Page 2
> ...
> Page N
>
> With Django I don't know of a convenient built-in way to do this. One
> could copy and paste N slightly-different versions of the navigational
> links template, but that isn't maintainable. One could manually pass
> in an extra context parameter in each of the N views, and add {% if %}
> tests in the template for each of them, but that's tedious.
>
> What I want is the ability to write a custom template tag that uses
> the same parameters as the tag {% url pageN %}, but which acts as a
> conditional and does something different if the parameter matches the
> currently active urlpattern. E.g., I could write a block tag {%
> ifactive pageN %}:
>
> Page 1
> Page 2
> ...
> Page N
>
> It doesn't seem like this can be done with standard Django because the
> request doesn't have a reference to the URL pattern that was actually
> used. My idea (implemented in my local version of Django) was to
> modify RegexURLResolver to return the urlpattern that was used, and
> store that (as well as the kwargs) as a property of the request.
>
> Does this seem like a useful patch? Or is there a better way to
> accomplish this?
>   
Some general advice, which may not all be relevant to your specific
circumstances. While including templates has its place, it's often
simpler and easier to use template inheritance ("{% extends ... %}")
instead. Look at context managers. You want to avoid doing as much of
that stuff in templates as you possibly can - it can get ugly real
quick, whereas in pure Python it's much more natural to express that
sort of thing.

Have the context manager build an appropriate list for the specific
page, and then just have the template render whatever list the context
manager builds. There's a balance to be struck between template
complexity and Python complexity.

This can also keep your template structures simpler. In holdenweb.com
more of the pages are stored in the database, and each page can be
associated with a section. You will notice, for example, on

  http://holdenweb.com/contact/

that the "Contact Holden Web" link in the left-hand nav bar isn't
actually a link (I have an aversion to self-linking pages). The part of
the context manager that builds the left-hand nav data reads

lNavSecs = Section.objects.filter(secpos="L").order_by("secsequence")
for sec in lNavSecs:
sec.pages = Page.objects.filter(pagsecid=sec.secid). \
exclude(pagsequence=0).order_by("pagsequence")
hpdict["lNavSecs"] = lNavSecs

The navigation is rendered in the base template, which all other site
pages (except the front page) extend, and the template section that
renders it reads


{% for sec in lNavSecs %}



{% for p in sec.pages %}
{% ifequal path p.pagpath %}
{{ p.pagdoctitle }}
{% else %}
{{ p.pagdoctitle }}
{% endifequal %}
{% endfor %}


{% endfor %}


It's usually easier to iterate over a sequence of some kind than putting
lots of special-cased stuff in the template.

Hope this helps.

regards
 Steve



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

[Steve Holden]

Calvin Spealman wrote:
> On Wed, Oct 29, 2008 at 9:48 PM, Dave Smith <[EMAIL PROTECTED]
> > wrote:
>
> I'm wondering who that's going to confuse. It's very clear that
> the template language
> isn't Python, so I'd think it'd make the most sense to use a
> keyword that makes sense
> within the context of the template language. I'd think that either
> 'else' or 'ifnone' are the
> most memorable/readable. 'default' connotes "unless we override
> ...", which isn't what's
> going on here.
>
> +1 for else
>
>
> The template language may not be sold as "python in html" but there
> are still obvious relationships between the constructs the two share.
> Breaking assumptions then simply isn't good for anyone involved.
>
> +1 for a default, -1 for calling it else
>  
+1 to both the +1 and the -1. It *will* confuse Python programmers who
also happen to write templates, and personally I think {% empty %}
expresses the meaning much more clearly to all classes of user.

regards
 Steve


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

[Steve Holden]

Jacob Kaplan-Moss wrote:
> I'm with Steve::
>
> {% for %} ... {% default %} .. {% endfor %}
>
> ... seems best.
>
>   
Agreement is great, but my suggestion was actually

{% for %} ... {% empty %} ... {% endfor %}

I feel this says more than "default", which requires you to think about
when the default value is required.

regards
 Steve


--~--~-~--~~~---~--~~
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.0.1 release blockers?

[Steve Holden]

Karen Tracey wrote:
> On Fri, Oct 31, 2008 at 6:38 AM, mrts <[EMAIL PROTECTED]
> > wrote:
>
>
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?
>
>
> Really, there is not reluctance to get input on what should be fixed
> before 1.0.1 is released.  It's just that input in the form of working
> patches with tests and doc is far more valuable than a simple bit on a
> ticket.  The list of tickets that are ready for checkin is not so big
> (and some of them are enhancements so not candidates for 1.0.1.
> ) that we need some other bit to say "look at this
> before releasing 1.0.1".
>
>
> The only major issue I have encountered is
> http://code.djangoproject.com/ticket/8882
> that makes inline formsets that have unique fields (that is, pretty
> much every other use case for them) unusable. Looks like brosner is
> already working on it -- thanks! -- and it would be perhaps wasteful
> if 1.0.1 is released before he has finished. 
>
>
> It really depends on how close a fix is as to whether it would be
> worthwhile holding up a bugfix release on any one ticket. I'm not
> talking about this ticket in particular (which I haven't looked at and
> it sounds like it's already on others' radars so likely will get in,
> assuming it's not too terribly difficult to fix) -- I'm trying to get
> across that holding up a bugfix release in hopes of a not-yet-existent
> fix for a bug that's already in a shipped release doesn't make much
> sense, unless you've got some reason to believe a fix will be
> appearing real soon now.  There are already many bugs that have been
> fixed in the 1.0.X branch and will benefit users.  1.0.1 will be
> better than 1.0, and 1.0.1 released in the very near future with n-x
> bugs fixed is better than 1.0.1 released at some unknown future data
> with those those additional x bugs fixed.
>
Well right, that'll be 1.0.2 if it's needed. Though with 1.1 on the way
it seems less than likely.

regards
 Steve


--~--~-~--~~~---~--~~
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: contrib.comments: working example must make a boost.

[Steve Holden]

Valery wrote:
> Hi all, @mtredinnick, @jacob, @wilson, @ubernostrum
>
> not sure if any "community boosts" are at all wanted here, but finally
> django is not for a closed circle of django-gurus and things are for
> the larger audience, isn't it? :) so, why there is no easy-to-launch
> example of last contrib.comments code?
>
> Look, I've spent about 3 (three) hours in total on 1.searching the
> example, 2. trying to get stable version somehow working according to
> wiki, then 3. the "trunk" things running according to wiki.The stable
> things are too old. The trunk's ones are too young. In the case of
> contrib.comments as I see it now, I'd definitely stick to trunk. How
> could one get it somehow usable? -- Examples are needed.
>
> A simple rule of mine regarding the community and bounce rate:
>
> * 1 person who is leaving after having no success in 3 hours equals
> to:
>
> * 2 more pragmatic persons who stop after 1.5 hours of no success --
> and this is equal to:
>
> * 4 of even more pragmatic persons who stop after 45 min of no success
> trying the things they need for their Goal... and? what does it
> equal? :)
>
> * 8 pers and 25 mins ...
>
> * 16 pers and 15 mins
>
> * 32 pers and 10 mins
>
> * 64 pers and 5 min :)
>
> * 128 pers looking at WORKING live demo!
>
> * 256 pers who never seen even the demo but have been reading in blogs
> how cool has been the experience about django and its
> contrib.comments.
>
> Sum them all up.
>
> Just single me and those hundreds. I don't want really enter the long
> discussions. I'd like to know how could I help getting such an example
> running. (Of course, I have some work copy)
>
>   
With a positive attitude like that I *really* hope you will be at the
PyCon sprints next year! As far as Django's concerned I'm pretty much a
user not a developer, but they do have a very knowledgeable and helpful
community on both sides of the line.

regards
 Steve


--~--~-~--~~~---~--~~
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: contrib.comments: working example must make a boost.

[Steve Holden]

Valery wrote:
> 
>> With a positive attitude like that I *really* hope you will be at the
>> PyCon sprints next year!
> 
> Chicago, IL -- uhhh, quite far... :)
> 
Maybe so, but it *is* possible to apply for assistance with funding. Not
all such requests can succeed, but you could consider applying. Keep
your eye on us.pycon.org.

> 
>> As far as Django's concerned I'm pretty much a
>> user not a developer, but they do have a very knowledgeable and helpful
>> community on both sides of the line.
> 
> OK, Steve, consequences? I have a bad looking form after following the
> trunk's wiki, in my form I can see - entries without any
>  tag at all and this all when those guru's are telling me
> "tables is a bad thing, just let the content flow!"
> 
> Ok, I am kinda equipped with a DIV-magic wand and am quite happy to
> let the content flow, just let me know my contrib.comment-
> friends are :)
> 
I'm no CSS angel, but holdenweb.com now only uses a table layout for the
home page. It does make the inner pages much more flexible. My latest
attempt (as test.holdenweb.com) currently breaks in IE ...

> Whatever friends, definitely, it is not the biggest prob we are
> facing :)

No, but for well-designed web systems good HTML and CSS is important.

> I wish you a nice evening and a nice weekend coming.
> 
> Looking forward to hearing from you
> 
K hope you have a good weekend also.

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: Proposal: Composite Foreign Keys

[Steve Holden]

Malcolm Tredinnick wrote:
> 
> On Thu, 2008-11-13 at 19:50 -0800, David Cramer wrote:
>> I was thinking beyond just handling Foreign Keys actually when I wrote
>> this up. It would allow for a more generic version of a generic
>> foreign key.
> 
> Generic relations are quite different to foreign keys and the two
> shouldn't be merged.
> 
> Generic Relations say how to get from an object id and a content type to
> a remote object. They aren't a database-layer construct, although a
> database constraint to, e.g., the content-type table could be
> enforced(but that's not relevant here). ForeignKeys are a representation
> of a database constraint, always referring to same remote table. They
> are necessarily different concepts and I dont' think attempting to merge
> them is going to gain much in clarity. At some point when multi-column
> primary keys are supported, we might be able to work out a way for
> generic relations to handle them, but I'm not holding my breath about
> that and it's certainly a phase 2 or phase 3 thing. The reason it's
> almost impossible to support generic relations with arbitrary
> multi-column fields because the number of columns is, well, arbitrary
> (attempting to jam multiple remote values into one local database column
> is a bad idea, too. At some point the hacks mount up beyond the point of
> usefulness). That is, one content type requires one value, a different
> one requires two and a third content type might require four values to
> identify the object. I strongly suspect we'll end up just saying
> GenericRelation fields only work for single valued objects ids. Which
> isn't at all unreasonable, since Django's generic relation classes
> aren't really compulsory for data modelling. Any given situation has a
> solution that doesn't involve them.
> 
>>  Although the more I think about it we'd still want to
>> magically handle ForeignKey's so the same problem exists.
> 
> There's no magic in programming. :-)
> 
> Maybe be you mean transparently. If so, I think this is a requirement,
> too, but it's not a problem. We know when the ForeignKey field is
> specified which model it refers to, so we can include the correct number
> of database columns at table creation time. We have perfect information
> when we create the table, which is where this differs from any generic
> relations.
> [...]
Does that apply even to recursive (reflexive) relationships, when the
related model must be specified by name rather than by reference? I
don't know enough about the internals to be clear on that, but it seems
like it could be problematic.

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: Proposal: Composite Foreign Keys

[Steve Holden]

Malcolm Tredinnick wrote:
> On Thu, 2008-11-13 at 23:47 -0500, Steve Holden wrote:
> [...]
>   
>>> Maybe be you mean transparently. If so, I think this is a requirement,
>>> too, but it's not a problem. We know when the ForeignKey field is
>>> specified which model it refers to, so we can include the correct number
>>> of database columns at table creation time. We have perfect information
>>> when we create the table, which is where this differs from any generic
>>> relations.
>>> [...]
>>>   
>> Does that apply even to recursive (reflexive) relationships, when the
>> related model must be specified by name rather than by reference? I
>> don't know enough about the internals to be clear on that, but it seems
>> like it could be problematic.
>> 
>
> It needs to be taken into account, but it's certainly solvable and not
> an obstacle to success. There are two solutions available:
>
> (1) Postpone creating the first table until we have read the second
> table so that we know the number of columns. This isn't too hard,
> although it means you end up making two passes over some classes'
> internals in some cases. But table creation is such a rare event and the
> Python code is so fast that it's easily affordable. We're not talking
> about something changing from 15 minutes to 20 minutes or anything.
>   
Sure. Perhaps it's not common terminology: by "recursive" I meant a
self-referential relationship, though now you mention it I see that the
same issue can occur if the order of model definitions is sub-optimal.
> (2) The poor-man's approach is "ALTER TABLE", which is a small-ish
> change, but butt ugly. I prefer the former solution, but the this is the
> silly drop-in I've got at the moment just to make things possible to
> develop with.
>   
I can see why, from a purist point of view, you'd rather not use it.
Doesn't mean it couldn't be useful as a first implementation, though.
> Realise that the reason we have string-ified forwards references is to
> avoid the need for circular imports. But at some point we'll end up
> importing everything anyway and then we can go and look at the number of
> required columns. This is why forwards references work in the first
> place -- at a later time we go back and fix up the internal references
> to point to the Python objects in question. We can change table creation
> to operate similarly. It's not that hard.
>
>   
I understand that. I just don't have the smarts to be able to help right
now, but thanks for the explanations.

regards
 Steve


--~--~-~--~~~---~--~~
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: Multi-Threaded Dev Server

[Steve Holden]

Julian wrote:
> [...] I think some people want to use snippets like that [...]

Wouldn't you agree that's a pretty feeble use case for something as
potentially disruptive as multi-threaded serving? Particularly when the
CherryPy alternative is so readily available.

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: Proposal: Composite Foreign Keys

[Steve Holden]

Frank Liu wrote:
> I guess i thought the core developers would've added this proposal to
> the list (judging from the title of this thread).
>
> Regardless, even if this had been added, it would've been given a -1
> anyway, judging from the readiness of this feature.
>
> More importantly though, my gripe about this is that if you go through
> a search for this feature, you would see entries from 2006. Over the
> last 2 years, there were multiple threads on this and yet nothing was
> really done to it. How many time have we seen attempts at integrating
> sqlalchemy and django? And really what features did people intend to
> add? It's really obvious (at least to me) that it's for the multi db
> support and composite primary key (I mean exactly what else does
> sqlalchemy do better, ok more backends, what else?). Why don't people
> get this?
>   
Whether people "get it" or not, proposing the integration of an entirely
different database front-end (it would be unfair to characterize
SQLAlchemy as an ORM: it's actually quite a lot more than that) is
almost certainly way too radical a step for a point release. It may well
be way too radical a step for release 2. OK, so it's an important use
case for you, but surely you can see that puts you in the minority, and
the development team have to think about the majority first.
> And let me correct myself a bit. It's not that no one has done
> anything, it's just that people have been only writing bits and pieces
> of hacks here and there to patch the flaws, but this problem has
> proven to be more difficult than just patches. For example, there are
> numerous suggestions in this thread in the API of the model. However,
> SO WHAT? does it matter? I like both. Both have merits. THEN WHAT?
> what about the admin layer, what this and that relationship, what
> about these recursive thing. Almost every one of these composite key
> threads had been stalled somewhere either in admin or the model api
> that nothing substantial was done. (usually a thread like this goes on
> a few 10s of exchanges and finally left cold...just like this one).
>
> And I think this is not the developers' fault. I think fundamentally
> there are 2 reasons for this: 1. the original design of the orm is not
> up to the task so that extending it proved to be too difficult. As
> have been mentioned in numerous places, the orm is one place where
> loose coupling should be taken with a grain of salt.
>
>   
Well whether this is true or not you can surely see that some kind of
radical change would be needed for you to have your pony. Or would you
disagree?
> 2 lack of leadership. To deal with this difficult situation, it is
> important to have the big guys like JKM (ok i don't know any other
> obvious names, but JKM here represent the core team) to say,  "ok now
> let's address the orm issues and this has to be done before release of
> 1.1" and so the smart minds of everyone else will start churning AND
> making those opinionated decisions that django is so famous for (which
> most of time is really brilliant). But no, JKM never has any interest
> in this because either he doesn't work in an enterprise environment
> anymore (because he's too successful unlike the rest of us still
> working in an Office Space envrionement) or django had seen tremendous
> growth even without it, why bother. (what i mean to say here is JKM,
> please post a note on the main site and mobilize your goons to address
> this issue. I am pretty sure it would be done before i go to work
> tomorrow).
>
>   
I think this not only mischaracterizes Jacob's leadership of the
project, it also mischaracterizes the relationship between Jacob and the
other core developers. Further, it does so in a somewhat unpleasant way
which I hope you will retract, as none of the core developer I've come
across could be described as "Jacob's goons". We don't need this
unpleasantness on a list which is intended to discuss the future of a
large software framework, and it can serve no useful purpose.
> Finally, don't get me wrong, i love django and python. It is simply
> the best language and best web framework out there for me (where
> enterprise reporting fit beautifully into a micro-app type of
> architecture instead of pylons or turbogears full blown application
> architecture for each report). But the orm really drives me crazy. Of
> course we all wrote custom managers, and overriding save to deal with
> the composite key short comings, but come on, there's gotta be some
> more pythonic (battery-included, there's only 1 obvious way) way of
> dealing with this.
>
>   
Well, you've certainly expanded on your frustration. To say that the
required changes could be made in less than 24 hours is a breathtaking
oversimplification, however. If you believe it, then roll your own
sleeves up and you could surely have it done by the end of the week.

Open source, remember? This means that leadership is a bit like herding
cats. I think you just took a good shot at 

Re: Using a HTML to fire off a data processing script on the server (REST or SOAP)

[Steve Holden]

Shao:

This is a very general question, and is only indirectly connected to
Django, since the task could be performed in most web frameworks.
However, the django-dev list is reserved to discussions about the
development *of* Django.

For questions about development *with* Django you should address the
django-users list.

Thank you.

regards
 Steve

Shao wrote:
> Dear ALL,
>
> I am very much interested in using a HTML to fire off a data
> processing script to run over the internet.
>
> I will be very grateful if you can advise me on passing parameters
> from an HTML form to a script and fire the script off to carry out
> full execution, monitor its progress and return an innerHTML with link
> (a name string of) the file generated back to allow user to download
> the result.
>
> The script run over a period of 2 to 3 minutes.
>
>
> Necessary are  the following steps:
> * user submits data to the server from a web page using an HTML form;
> server redirects the browser to a status page that says "script is
> running";
> * in the background, the server fires off a worker script that does
> the job; the server monitors the script to see when it's done (this
> monitoring can be tied to the status page: when the user reloads the
> status page, the server looks at the script to check if it's done);
> * user refreshes the page (or the page refreshes itself) until script
> is finished, and the page says "script finished; here are the results"
> * some kind of cleanup of data, either with a cron job or manually by
> the user
>
> Regards.
>
> Shao
>
> >
>
>   



--~--~-~--~~~---~--~~
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: order_by with distinct behavior in orm

[Steve Holden]

Malcolm Tredinnick wrote:
[...]
> Hopefully, MySQL will fix their bug one day. That's the way to resolve
> this.
> 
Just so long as nobody holds their breath waiting ...

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: Template-04's scope

[Steve Holden]

Jacob Kaplan-Moss wrote:
> On Tue, Nov 25, 2008 at 10:11 AM, Johannes Dollinger
> [...]
>> * I always felt the API for custom tags is too verbose.
>> 
>
> There's almost universal agreement on this point :)
>
> It's unfortunately pretty tricky to do in a backwards-compatible way:
> we've sorta pasted ourselves into a corner here by letting tags do
> anything they want in terms of parsing. This lead to an inconsistency
> in syntax that we (unfortunately) have to continue to support.
>
> However, that's no reason not to have a better API on top that
> third-party tags can use -- as long as internal tags don't break.
>   
Heretical suggestion: {: :}, {! !}, {$ $} or {[ ]} with a different
processor (falling back to the original if necessary), and therefore no
need for a fully backwards-compatible approach?

regards
 Steve


--~--~-~--~~~---~--~~
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: floating point django.VERSION element versus adding another element to the tuple

[Steve Holden]

J. Cliff Dyer wrote:
> As you said, it's a bikeshed argument, so I'm not going to push hard on
> this, but I do want to put one thing out for discussion.  There is some
> value in making versions increase in sort order, so you can do "if
> django.VERSION > target:".  If 'final' were changed to 'release', this
> would work.  'beta' < 'rc' < 'release' < 'svn'.
>
> Just a thought.
>
> And to throw a wrench into everything, including my own thought, what
> would branch versions look like in your scheme?
>
> Cheers,
> Cliff
>
>
> On Fri, 2008-04-18 at 12:46 -0500, James Bennett wrote:
>   
>> And because lately we've been doing various specification-type things,
>> I'd like to propose (with release manager hat firmly planted on my
>> head) that going forward we do things in the following fashion.
>>
>>
>> Format of ``django.VERSION``
>> 
>>
>> ``django.VERSION`` is a 3-tuple, of the form::
>>
>> (major-version, minor-version, modifier)
>>
>>
>> Packaged releases
>> =
>>
>> In a packaged release, the elements of the ``django.VERSION`` tuple
>> are:
>>
>> 1. The major version tree from which the release is packaged.
>>
>> 2. The minor version the package represents.
>>
>> 3. A modifier indicating the release status of the package.
>>
>> The modifier may take any one of the following four forms:
>>
>> 1. 'beta'; this is a beta leading up to a final release, and ''
>>represents the number of the beta release; the first beta for 1.0,
>>for example, would be (1, 0, 'beta1'), the second beta for 1.0
>>would be (1, 0, 'beta2'), etc.
>>
>> 2. 'rc'; this is a release candidate leading up to a final release,
>>and '' represents the number of the release candidate; the first
>>release candidate for 1.0, for example, would be (1, 0, 'rc1'), the
>>second release candidate for 1.0 would be (1, 0, 'rc2'), etc.
>>
>> 3. 'final'; this is the packaged release of a specific version of
>>Django, and represents a stable, tested version to which the Django
>>project commits support per the support/security policy. Django 1.0
>>would, for example, be (1, 0, 'final'), Django 1.1 would be (1, 1,
>>'final'), etc.
>>
>> 4. 'p'; this is a bugfix and/or security release for a prior
>>version of Django, released in accordance with the support/security
>>policy. The first such release for Django 1.0 would be (1, 0,
>>'p1'), the second such release for Django 1.0 would be (1, 0,
>>'p2'), etc.
>>
>>
>> SVN checkouts
>> =
>>
>> For an SVN checkout, the elements of the ``django.VERSION`` tuple are:
>>
>> 1. The most recent major version released at the time of the specific
>>SVN revision being checked out.
>>
>> 2. The most recent minor version released at the time of the specific
>>SVN revision being checked out.
>>
>> 3. The modifier 'svn', indicating an SVN checkout, where '' is
>>the revision of the checkout from the repository.
>>
>> So, for example, if you do an SVN checkout of revision 31337 and, at
>> the time of that revision, the most recent major version was 3 and the
>> most recent minor version was 14, then VERSION in your checkout will
>> be::
>>
>> (3, 14, 'svn31337')
>>
>>
>> Why this is a good thing
>> 
>>
>> How to do the version tuple is mostly a bikeshed argument. Ultimately,
>> three things matter in deciding how to handle it:
>>
>> 1. The BDFLs/core dev team are OK with it.
>>
>> 2. The system used is consistent.
>>
>> 3. The system used is easy to parse into human-readable formats.
>>
>> The above system meets (2) and (3) -- it offers a version tuple in a
>> consistent format, and one which is easy to turn into a human-readable
>> string like "Django 3.2", "Django 1.4-beta3" or "Django
>> 2.18-svn28183".
>>
>> The only question is whether it meets (1). Thoug
Without wishing to turn this into a long-drawn-out discussion, why be 
willfully different from Python itself? From 2.0 on there's been a 
standard of sorts in sys.version_info:

"""*version_info*

A tuple containin

Re: SVN Milestones

[Steve Holden]

Kenneth Gonsalves wrote:
> On 19-Apr-08, at 8:52 PM, James Bennett wrote:
>
>   
>> On Sat, Apr 19, 2008 at 10:17 AM, ydjango <[EMAIL PROTECTED]>  
>> wrote:
>> 
>>>  Is there a reason you cannot call it just 1.0
>>>   
>> So would you prefer to have a beta-quality product whose developers
>> lie and call it 1.0?
>> 
>
> I wouldn't even call the current svn head a beta-quality product
>
>   
Which is probably why it isn't yet a beta release?

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: SVN Milestones

[Steve Holden]

Kenneth Gonsalves wrote:
> On 20-Apr-08, at 12:47 AM, Steve Holden wrote:
>   
>>> I wouldn't even call the current svn head a beta-quality product
>>>
>>>   
>> Which is probably why it isn't yet a beta release?
>> 
>
> what I meant is that it is stable and production ready and that it is  
> time people stopped evaluating products by looking at the version  
> numbers
>   
Stable and production-ready until the new functionality that's due "real 
soon now" comes in.

I don't think it's unreasonable of people to wait until there is an 
announcement of future stability, which is effectively what 1.0 will 
represent. At the moment I would agree that (even) more people could 
probably use the trunk version for production systems, but it's human 
nature for some people to crave stability and want to avoid changing 
code to keep in step with current versions, so they stay away from 
Django because they know that /something/ is due to change, though they 
may not know the details of newforms admin or queryset refactoring.

We can probably agree that the sooner 1.0 comes out the better it will 
be for Django takeup, but that doesn't mean a compromise on quality is 
acceptable.

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: API question for model saving

[Steve Holden]

David Larlet wrote:
> Le 28 avr. 08 à 09:33, David Danier a écrit :
>
>   
>>> Sometimes when calling save(), we know (for business reasons) that it
>>> must create a new object or raise an error. Similarly, in other  
>>> cases,
>>> it either must update an existing object or raise an error.
>>>   
>> I think discussion about this issue has been on this list before, last
>> time someone suggested adding create() and update()...and keeping  
>> save()
>> as an method calling these two, like:
>> -8<
>> class Model(...):
>>  def save(self, ...):
>>  if self.has_pk() and self.pk_exists():
>>  self.update()
>>  else:
>>  self.create()
>>  def update(): ...
>>  def create(): ...
>> >8-
>>
>> So what is the big advantage of having an new parameter in save() like
>> you suggested? With having create()/update() you can do similar  
>> things.
>>
>> Additionally it would be possible to override only parts of the
>> save()-logic in classes extending Model (for example when needing to
>> calculate field-values on create, but not on insert...which is  
>> currently
>> difficult).
>>
>> And, of course, you would have no problems with naming the new  
>> parameter
>> and difficulties in creating self-explaining possible values ("not
>> must_create", rather than "must_not_create").
>> 
>
> I'm +1 on this solution, which turns the well known pattern:
>
> def save(self):
> if not self.id:
> self.some_date = datetime.now()
> super(Model, self).save()
>
> to:
>
> def create(self):
> self.some_date = datetime.now()
> super(Model, self).create()
>
> BTW, create()/update() sounds more explicit to me than save().
>   
You could argue that the separate-method solution has better cohesion. 
Malcolm's point that this is very much a minority use-case, and that 
mostly the two methods will anyway simply call a modified save with 
alternative values of the flag (whose names are a little smelly, by the 
way) is reasonable, I suppose.

But it does seem to me that create() and update() are more explicit than 
save(must_create=True) and/or save(must_update=True). The separate 
method solution also removes the possibility of the illegal fourth case 
(must_update==must_create==True), which means there would be no need to 
test for it.

In summary, we are arguing around the ragged edges of an overall very 
neat system.

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: API question for model saving

[Steve Holden]

Malcolm Tredinnick wrote:
> Hey David,
>
> On Mon, 2008-04-28 at 12:21 +0200, David Larlet wrote:
> [...]
>   
>> def save(self):
>> if not self.id:
>> self.some_date = datetime.now()
>> super(Model, self).save()
>>
>> to:
>>
>> def create(self):
>> self.some_date = datetime.now()
>> super(Model, self).create()
>> 
>
> For this particular case it saves a whole line. One concern I have is
> that if there's more complex logic in your overridden save method, some
> of it is going to be useful in both cases and now you have to create
> extra sub-functions for the common bits and remember to call them both
> times. It leads to duplication. If you look around at sample code on
> django-users and other places, you can see people doing a number of
> pieces of auxilliary processing as a result of save happening on the
> instance, so this isn't a trivial issue.
>
>   
>> BTW, create()/update() sounds more explicit to me than save().
>> 
>
> Which immediately leads to one of the problems with it. Suppose I'm
> writing a function that accepts objects, does something to them and then
> wants to save them. Do I call create() or update()? There's no way to
> tell. Currently, I call save() with no ambiguity problem.
>
>   
I s'pose that's the killer to the separate-methods argument.
> Also, this presents an unnecessary backwards-incompatibility. Every
> single piece of code now has to change to use one or other of these
> methods. Every save() call. Currently and with the parameter approach,
> *zero* existing code has to change initially. If you want to support the
> must insert vs. must update difference, you can add a parameter (or two,
> depending on which approach we take) and it's still backwards
> compatible.
>   
How do these parameters get set for the above "function that accepts 
objects and wants to save them"? Presumably it too has a default 
"must_create"?

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 port on OpenVMS - Oracle/Rdb backend

[Steve Holden]

Jean-François wrote:
> Any comment, especially on the transaction model?

If you want considered opinions you would do well to wait longer than 51 
minutes!

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 port on OpenVMS - Oracle/Rdb backend

[Steve Holden]

Don Spaulding II wrote:
> 
> 
> Collin Grady wrote:
>> Steve Holden said the following:
>>   
>>> If you want considered opinions you would do well to wait longer than 51 
>>> minutes!
>>> 
>>
>> You should check the date as well as the time; he sent the first email
>> *two days* before the second.
>>   
> Steve, perhaps next year at pycon we could have a "Teach Me Google" BoF?
> 
Or a "Teach Me Common Sense"? So, now we've established I'm a bozo, will 
someone please answer his question!

regards
  Steve

PS: Completely off-topic apart from the "Teach Me Google", can anyone 
tell me why Google Groups/Gmail isn't sending me my own messages?
-- 
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: Lock-In

[Steve Holden]

In fact this question would be better addressed to a more general list, 
such as the comp.lang.python newsgroup (also available as 
[EMAIL PROTECTED]). See

   http://mail.python.org/mailman/listinfo/python-list

for further information.

regards
  Steve

[EMAIL PROTECTED] wrote:
> django-developers is meant for questions regarding the development of
> django itself, questions about the usage of django should be directed
> to django-users.
> 
> On May 4, 1:27 am, Kamal <[EMAIL PROTECTED]> wrote:
>> Question,
>>
>> I work in a company that is adopting the agile method, scrum. They are
>> doing implementing it using c#, which I think is funny.  How does a
>> company decide to switch its development language? We have very long
>> development cycle's, and I would have thought they would have looked
>> at the language they are using, but they laugh when that is suggested.
>>
>> Has anyone seen a company pull off a switch from a .Net / Sql based
>> environment to a Python / MySql sucefully? Where benifits seen?
> > 
> 


-- 
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: Subversion Access

[Steve Holden]

Rahein:

Please also note that you are supposed to adjust your path so svn is 
runnable from anywhere, not run svn in its bin subdirectory. Google for 
"set path" followed by your operating system name if you don't know how 
to do this.

regards
  Steve

Dan Watson wrote:
> Questions like this should be directed to the django-users mailing
> list.
> 
> That said, this is probably caused by your proxy server not
> understanding how to handle subversion's requests. See
> http://subversion.tigris.org/faq.html#proxy or search the mailing
> lists - this has come up before.
> 
> On May 7, 5:00 pm, Rahein <[EMAIL PROTECTED]> wrote:
>> I am trying to get the Django Trunk downloaded and this is my first
>> excursion into using Subversion.
>>
>> I followed the directions in the installing guide, but when I run the
>> command in subversion's bin folder:
>>
>> svn cohttp://code.djangoproject.com/svn/django/trunk/django-trunk
>>
>> I get these error message:
>>
>> svn: REPORT request failed on '/svn/!svn/vcc/default'
>> svn: REPORT of '/svn/!svn/vcc/default': 400 Bad Request (http://
>> code.djangoproject.com)
>>

-- 
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: range in templates?

[Steve Holden]

Mark wrote:
> I'm new to django so I apologize if after reading through the docs and
> list I missed something obvious. I would like to do something like
> this in a template:
> 
> {% for index in range(10) %}
> 
> but I can't seem to find anything that will allow this. I've become
> used to the idea that when something that should be easy seems hard I
> am usually going about it the wrong way, but in this case I'm pretty
> certain this logic belongs in the template. I've got space for 15
> image thumbnails, but when I only have say 5 thumbnails I want to fill
> the space with a standard filler thumbnail for purely aesthetic
> reasons.
> 
> The only alternative I can think of is to make an arbitrary list of
> the correct length in my view and pass it to the template, but this
> seems silly.
> 
> What am I missing?
> 
Well, the first thing you are missing is that the django-dev list is to 
discuss development *of* Django rather than development *with* Django. 
You want django-users, just down the corridor :-)

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