metrics: Django case study

[Gary Wilson Jr.]

For those interested, I've made available a couple reports from a
class assignment where we analyzed the Django codebase, bug tracker,
and wiki.  The motivation of these reports was to answer questions
related to code size, modularity, complexity, unit test coverage, and
component quality.

Instead of attaching the roughly 3.5MB worth of PDF reports in an
email to the list, I've made the reports available on my website:
http://thegarywilson.com/blog/2012/software-metrics-django-case-study/

For the lazy, here are several points mentioned in the papers:
* Since 2005, slightly more than linear growth of source lines of code
(SLOC) and number of files, with a noticeably faster SLOC growth rate
in the last couple years.
* Project started with 11k SLOC in July 2005 and has grown to over 70k
SLOC in Nov. 2011.
* Almost half of the SLOC within Django reside in the contrib package.
* Growth rate of "complex" files (files with at least one function
with cyclomatic complexity greater than 10) has also been nearly
linear over time, but at a lesser rate than the SLOC growth rate.
* Average complexity of files (weighted by SLOC) peaked in 2008 and
has been in a declining trend since.
* 10 files contained at least one function with cyclomatic complexity
greater than 20.
* Percentage of functions and classes with docstrings peaked in May
2009 near 50% and has been declining since (to near 40% in Nov. 2011).
* Packages with the lowest percentage of classes/functions/methods
with docstrings include: templatetags, http, template, and db.
* 16000 tickets: 63% not categorized.  Of the remaining, categorized
tickets: 59% bug/defect, 17% new feature, 15% enhancement, 8%
cleanup/optimization, 1% task.
* Ticket resolution times: At one month after opening 35% of new
feature tickets are closed compared to 50-80% with other ticket types.
* Average defect repair time (i.e. time to ticket close) is 65 days
(though varies from 127 days for tickets categorized as normal to 31
days for tickets categorized as trivial).  In general, average repair
time has steadily decreased over the life of the project.
* The components with the most defects reported are, in order:
documentation, database layer, contrib.admin, and core, which in total
account for almost 60% of all reported defects.
* If taken in aggregate, defects reported for apps in the contrib
package account for about 25% of all defect reports.
* 13% of all tickets submitted have been marked as duplicates.
* When normalized by size (defects per SLOC), core had the highest
defect density by far, followed by the database, forms, and templates
components.
* The most edited wiki page is the "DevelopersForHire" page.
* The wiki consists of 600 pages with an average of 0.26 attachments,
18.4 revisions, and 32512 characters.
* From 2007 to 2011, code coverage of the unit test suite more than
doubled, from 39% to 90%, with a large increase seen between the 0.96
and 1.0 releases.
* 59.3% of the non-zero-length modules had 95% or greater test suite
line coverage, and 40.3% had 100% coverage.

So, I think these reports show that there are some things Django is
doing well at (e.g. test coverage, avg. defect repair time
improvements, avg. complexity), and that there are some areas that
could be targeted for improvement (e.g. components with high defect
counts and densities, docstrings and source comments).

Thanks,
Gary

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

Re: auth.User refactor: reboot

[Gary Wilson Jr.]

On Wed, Mar 21, 2012 at 12:48 AM, Russell Keith-Magee
 wrote:
>
> On 21/03/2012, at 12:23 PM, Clay McClure wrote:
>
>> On Saturday, March 17, 2012 8:52:01 PM UTC-4, Russell Keith-Magee wrote:
>>
>> The only way I can see around this problem is to come up with a way for 
>> ForeignKey(User) to transparently become an effective 
>> LazyForeignKey('auth.User').
>>
>> I explored this a bit and found that, since the binding of 
>> ForeignKey('auth.User') is already deferred, it would be straightforward to 
>> defer binding of a model declared as "swappable", as you've suggested. My 
>> concern—and the reason I opted to go the pluggable auth app route—was that a 
>> deferred binding approach might also be needed in ModelForm[1] and model 
>> inheritance[2]. Even then, we would still have apps that expect to be able 
>> to use the User model they find at django.contrib.auth.models.User. I agree 
>> that lazy foreign keys would be a welcome addition to Django, but it seems 
>> to me we have some other problems to solve before they can replace auth.User 
>> in a backwards compatible way.
>
> I agree - that's why my original proposal was to make the LazyForeignKey 
> explicit -- that makes the adoption process opt in. Yes, this means that apps 
> need to be modified and advertised to be "1.5 swappable-User-compliant". 
> However, to my mind, that's a good thing, because you have an explicit marker 
> that the author of the app expects the app to work with an User model, or 
> that they've documented any specific requirements that the app needs to see 
> in a swappable User object.

I'm +1 on the concept of configurable models and the LazyForeignKey,
as it solves the general problem of model class
reusability/flexibility.  While the auth.models.User model is the most
common wart, I've come across plenty of instances where I would have
liked to more cleanly made use of particular models within a
third-party app that needed a bit of tweaking for a site's needs.

I'm not particularly thrilled about an explicit LazyForeignKey or
pluggable Meta class maker, though, because it requires that an
application author to actually make use of these features for an
application user to have the ability to extend any models the app has
defined.  In other words, I don't want to have to ask your permission
to extend and reuse your model, thank you.

I propose:

3b) IMHO, if we are able to make a wholesale change in all of the
needed places (models, modelforms, etc.), then we just make ForeignKey
lazy by default.  Unlike the other Solution 3 alternatives, it seems
that this could be made backwards compatible and also has the benefit
of requiring no code changes for third-party app authors.

3c) If we can't make the change all at once, or if it's decided that
making a model swappable really should be explicit, then perhaps an
alternate solution to the LazyForeignKey field or swappable Meta class
option proposals would be to introduce a new parameter to ForeignKey,
e.g.:

ForeignKey(User, swappable=True)

For backwards compatibility, the default would be swappable=False.
That way, if it were later decided that models should be swappable by
default, then we only need to change this parameter default to
swappable=True and any new/existing ForeignKey definitions
automatically get the new behavior (though behavior does not change
unless you've actually swapped out the model, of course).  In this
scenario, app authors would still need to go explicitly make their
models swappable, but wouldn't need to make any further changes if the
swappable parameter default were to change.

Thoughts?

Gary

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

Re: #7198 - Better error message when app is missing models.py

[Gary Wilson Jr.]

On Fri, Sep 9, 2011 at 4:35 PM, Justin Lilly  wrote:
> Not sure why this particular ticket is marked as DDN, as it seems like
> a no-brainer. The patch provides a more clear error message when a
> user is attempting to load an app which doesn't have a models.py.
>
> https://code.djangoproject.com/ticket/7198
> https://github.com/django/django/pull/39
>
> Happy to respond to any feedback, as I think this is a worthwhile
> change.

As Carl recently commented on the referenced ticket, the DDN was
likely due to a decision on whether or not to require a models.py at
all.

I'm a fan of not requiring a models.py, as IMHO it shouldn't be any
different than other common files found in an app e.g. urls.py,
templatetags dir, etc.  If I don't need any models for my app, then
why must I still have a models.py?  That said, it also seems there
could be some backwards incompatibilities if code or external tools
rely on a valid app including a models.py file.

For the record, about 20% of the models.py files in the django
codebase are empty (or just contain a comment):
$ find . -size -60c -name 'models.py' | wc -l
44
$ find . -name 'models.py' | wc -l
211

The issue of a missing models.py file also seems to be a frequent
visitor to our ticketing system:
https://code.djangoproject.com/ticket/3125
https://code.djangoproject.com/ticket/3310
https://code.djangoproject.com/ticket/4153
https://code.djangoproject.com/ticket/6883
https://code.djangoproject.com/ticket/7198
https://code.djangoproject.com/ticket/10661
https://code.djangoproject.com/ticket/13985
https://code.djangoproject.com/ticket/15605

...and there's been a few occasions where we've had our own issues
with missing models.py files:
https://code.djangoproject.com/changeset/6991
https://code.djangoproject.com/changeset/7950
https://code.djangoproject.com/changeset/12156
https://code.djangoproject.com/changeset/12170
https://code.djangoproject.com/changeset/13670

Gary

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

ANN: Sprint in Austin, TX this Saturday, Jan. 22

[Gary Wilson Jr.]

See the wiki page for more details and to sign up:

http://code.djangoproject.com/wiki/Sprint2011JanAustin

Gary

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

safe characters used in iri_to_uri (#12445)

[Gary Wilson Jr.]

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

RFC 3986 [1] defines the following as "reserved" and "unreserved" characters:

reserved= gen-delims / sub-delims
gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

...and states that:
* if data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
* unreserved characters should not be percent-encoded

So, a couple issues here:

1) From my understanding of this, it seems that we need to add the
characters: ' (single quote), @ (at sign), and ~ (tilde) to the list
of safe characters used in iri_to_uri and drop the % (percent)
character.  The ' and @ are reserved characters that are currently
missing from our list of safe characters, and the ~ is the only
unreserved character that urllib.quote doesn't already consider safe
[2].

Does this sound right, or am I misinterpreting the RFC?

2) The % character is not a reserved or unreserved character, but at
the end of section 3.1 of RFC 3987 [3] (which the source references)
states that % must not be converted:

"Systems accepting IRIs MAY also deal with the printable characters in
US-ASCII that are not allowed in URIs, namely "<", ">", '"', space,
"{", "}", "|", "\", "^", and "`", in step 2 above.  If these
characters are found but are not converted, then the conversion SHOULD
fail.  Please note that the number sign ("#"), the percent sign ("%"),
and the square bracket characters ("[", "]") are not part of the above
list and MUST NOT be converted."

Which I interpret as: even though % is not a reserved or unreserved
character, it should not be percent-encoded.  So we keep % in our list
of safe characters, sound right?

Gary

[1] http://www.ietf.org/rfc/rfc3986.txt
[2] http://docs.python.org/library/urllib.html#urllib.quote
[3] http://www.ietf.org/rfc/rfc3987.txt

--

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

Re: Summer of Code: mentors wanted

[Gary Wilson Jr.]

On Thu, Mar 19, 2009 at 5:41 PM, Jacob Kaplan-Moss  wrote:
> If you'd like to mentor a Summer of Code project, you can apply through
> Google's web app right now. Please also add your name here:
> http://code.djangoproject.com/wiki/SummerOfCode2009

FYI, django mentor signup is here:

http://socghop.appspot.com/mentor/request/google/gsoc2009/django

Gary

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

Re: #3182 -- model instance update() method and QuerySet update_or_create() method

[Gary Wilson Jr.]

On Sun, Mar 15, 2009 at 4:40 PM, Malcolm Tredinnick
<malc...@pointy-stick.com> wrote:
> On Sun, 2009-03-15 at 12:12 -0500, Gary Wilson Jr. wrote:
>> Another option would be to allow Model.update() to take the
>> force_update and force_insert parameters that save() does and just
>> pass these through to the save() call.
>
> Aside from the fact that I dislike the ideal as a whole (see below), if
> you're going to have a method called update(), it should do what it says
> on the box. It's not called maybe_create_maybe_update() -- we already
> have that method (it's spelled "save()").

This is the way I lean too, having update() use
save(force_update=True).  We already have Model.__init__ and
Manager.create() for creation.

>> What do you think?
>
> I'm very unconvinced that the idea in the ticket is worth it. It's a
> two-liner if somebody wants to do this in their code, so whilst we *can*
> add this method, adding yet another thing to Model namespace that also
> adds to the documentation and things that need to be tested, etc,
> doesn't seem worth it to me. We already have save(force_update=True) to
> do an update. Adding the extra line to also populate some model fields
> doesn't seem like a great API addition that we can't live without to me.

Sure, the model update() method is a convenience that we can live
without, but I would argue that it rounds out CRUD for models and
makes things a bit more readable:

obj.update(field1=value1, field2=value2)

instead of:

obj.field1 = value1
obj.field2 = value2
obj.save(force_update=True)


IMO, the update_or_create is a bigger win, since otherwise you would
have something like:

defaults = {'field2': value2, 'field3': value3}
obj, created = get_or_create(filed1=value1, defaults=defaults)
if not created:
obj.update(**defaults)

...which, by the way, without a Model.update() method would look like:

defaults = {'field2': value2, 'field3': value3}
obj, created = get_or_create(filed1=value1, defaults=defaults)
if not created:
for k, v in defaults.iteritems():
setattr(obj, k, v)
obj.save(force_update=True)

...but with update_or_create looks like:

obj, created = update_or_create(filed1=value1, defaults={'field2':
value2, 'field3': value3})


With Model.update() and Manager.update_or_create(), we are saving two
to five lines of code for operations that are fairly common.

Gary

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

#3182 -- model instance update() method and QuerySet update_or_create() method

[Gary Wilson Jr.]

I've just attached an updated patch:

http://code.djangoproject.com/attachment/ticket/3182/3182.2.diff

Before I committed this I wanted to ask the list their thoughts of
Model.update() doing a save(force_update=True).  Currently the patch
is just calling save(), which allows one to call update() on an
unsaved model instance.  However, I think the more common scenario
would be updating an object just fetched from the database, in which
case a force_update=True would be ideal.

Also, QuerySet.update_or_create() calls Model.update() if the object
already exists, and in this case force_update=True should also be
used.

Another option would be to allow Model.update() to take the
force_update and force_insert parameters that save() does and just
pass these through to the save() call.

What do you think?

Gary

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

Re: Call for review: #689 - REMOTE_USER authentication

[Gary Wilson Jr.]

On Fri, Mar 13, 2009 at 9:48 PM, Malcolm Tredinnick
 wrote:
> I'd go for something shorter:
>
>        Performs any cleaning on the "username" prior to using it to
>        create the user object. Returns the cleaned username.
>
>        By default, returns the username unchanged.
>
> I've also added when the method is called, since that adds some context
> to the purpose of the method (it's post-input, pre-ORM handling). I'm

Changed docstring, using your example.

> ambivalent about whether the LDAP example goes there or in the docs, but
> I'd favour something shorter.

I've moved these mentions to the docs.

> 2. Regarding the middleware: How does this interact with WSGI-based
> systems? Can remote user data be passed in the environment via some
> standard wsgi.* variables, rather than a particular HTTP header there?
> It would be good to be able to reuse the same middleware (or make it
> minimally subclassable) for that case, rather than unnecessarily burning
> bridges.
>
> Not suggesting you necessarily implement WSGI authentication support,
> but it would be good to know if there's anything relevant we need to be
> aware of in the design. Mostly I was looking at the reliance on a
> particular HTTP header and wondering if that was the only way we might
> enter that path.

I'm pretty sure the middleware as it stands now would easily be able
to support WSGI authentication.  The mod_python handler is actually
populating META['REMOTE_USER'] from the mod_python request object's
user attribute.  The wsgi handler sets META to the the environ dict it
is passed:

class WSGIRequest(http.HttpRequest):
def __init__(self, environ):
...
self.META = environ

So if REMOTE_USER is in the environ dict then the RemoteUserMiddleware
will work unchanged.  If the authenticated user is passed as some
other environment variable name, then one would just need to subclass
RemoteUserMiddleware and set the header attribute to whatever key to
lookup in META.

> 3. Not sure about howto/ vs. topics/ for the new document, in reference
> to Jacob's comment, since it's mixing both instructional / tutorial form
> with reference manual. Your call. Not worth sweating too much, since we
> need to spend some time editing in some separation there in general and
> the current stuff you've got looks very clear (I understood it).

Looking, at what's currently in each I can see how this might be a
better fit for howto.  I'll move it, Jacob.

> Good stuff.

Many thanks are in order to those who worked on the patch before I touched it.

Gary

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

Call for review: #689 - REMOTE_USER authentication

[Gary Wilson Jr.]

Just posted an updated patch:

http://code.djangoproject.com/attachment/ticket/689/689.4.diff

Gary

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

Re: Option to disable messages in auth context processor

[Gary Wilson Jr.]

On Thu, Feb 5, 2009 at 9:07 AM, Jacob Kaplan-Moss
 wrote:
> On Thu, Feb 5, 2009 at 9:01 AM, Vinicius Mendes  wrote:
>> So I decided to write a new messages app and it works very well, the only
>> problem is the django.core.context_processors.auth.
>
> Yeah, this processor has a bunch of bugs in it. I think Malcolm and I
> figured out that there's something like five different bugs -- not bad
> for three lines of code!

Are these documented anywhere, by chance?

I know the get_and_delete_messages call is problematic because it
causes evaluation of the LazyUser object created by the
AuthenticationMiddleware.  This causes both an access to the session
(causing #6552 - Vary: Cookie [1]) and an extra query on every request
to grab the user.

What are the other issues?

Gary

[1] http://code.djangoproject.com/ticket/6552

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

Re: Dropping Python 2.3 compatibility for Django 1.1

[Gary Wilson Jr.]

On Wed, Nov 26, 2008 at 7:23 AM, varikin <[EMAIL PROTECTED]> wrote:
> On Nov 25, 7:16 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>> However, even saying Django 1.1 is the last 2.3-compatible version and
>> we drop it afterwards gives us a reasonable 3.0 support timeline, since
>> our timeframe doesn't really encourage any official 3.0 support for 1.1.
>
> I am +1 to saying 1.1 is the last release for 2.3 (or just deprecated
> and dropped sometime in the future). Pulling support for something is
> large step and was never discussed for 1.1 openly till now. Anyone who
> has read the roadmap but not following any more than that could be in
> for a nasty surprise.

Actually, dropping 2.3 support was openly discussed for 1.0 at PyCon
2008.  In a room with at least 60 developers, I was the only one that
raised my hand when Jacob asked about people using Python 2.3 (I had
RHEL4 boxes in production).  Also at PyCon, the core developers later
decided to keep 2.3 support for 1.0 and drop it shortly afterwards
(Jacob, looks like we still need to post those meeting minutes:
http://www.djangoproject.com/foundation/records/).

Digging through my notes here, it seems that a big reason for keeping
Python 2.3 support for 1.0 was for the benefit of the
Jython/IronPython/PyPy folks.  I'm not sure how these areas have come
along since then.  jython.org seems down at the moment, but from the
IronPython page, I gather they are at CPython 2.4 and 2.5
compatibility levels [1] with their 1.x and 2.x releases,
respectively.  If Python 2.3 support still helps these folks then then
I would be in favor of keeping 2.3 support around for 1.1.

Otherwise, I'm all for dropping 2.3 support, as maintaining 2.3
support is not fun at all.  Just dig through changesets and note all
of the 2.3 bugs that were introduced and fixed over the last major
development cycle, for example.  Python 2.3 unicode bugs have been the
most annoying, but there have been a few rsplit, list generator, and
other syntax bugs as well.  Testing is made easier, too, since it
means one less version of Python to test against.

As for the roadmap, I think that is the point of this discussion.  We
are finalizing the features for 1.1, and if Python 2.3 support is to
be dropped, then this fact will indeed need to be noted on the roadmap
along with the other planned features.  Those needing to stay on
Python 2.3 could just keep to 1.0.x, not unreasonable if you ask me.
Also, 1.1 is still four months away and 1.0.x will be receiving bug
fixes until then, so Python 2.3 users wouldn't be completely left in
the dark.

Gary

[1] http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Differences

--~--~-~--~~~---~--~~
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: Last call for 1.0 alpha

[Gary Wilson Jr.]

Jacob Kaplan-Moss wrote:
> [If you happen to be at OSCON I'll be working on 1.0 alpha on the
> lower floor over by the Starbucks if you wanna come over and help
> out.]

I'm not at OSCON, but I can take care of #7864 (docs renaming), as I've 
got a patch already in the works.

Gary

--~--~-~--~~~---~--~~
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: Reminder: "Must-have" feature freeze in two weeks

[Gary Wilson Jr.]

Jacob Kaplan-Moss wrote:
> For my part, I plan to work on #2 (oldforms -> newforms in generic
> views) late this week. Brian's patch is pretty much perfect, so it's
> just a matter of a code review and a check in.

Jacob, FYI I just posted an updated patch for #3639 [1] that factored out some 
duplicate code and added a few more tests.

Gary

[1] http://code.djangoproject.com/ticket/3639

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

tickets and use of the 1.0 milestones

[Gary Wilson Jr.]

I would like to remind those out there setting milestones on tickets to 
follow the following guidelines that Jacob put forth:

   * Must-have feature bugs go in the "1.0 alpha" milestone. These 
basically should be all nfa-blocker tickets. Bugs in the must-have 
features are not to be part of this milestone; they can be fixed after 
the alpha and should be put in the "1.0" milestone.

   * Any feature tickets related to the maybe list get put in the "1.0 
beta" milestone.

   * Any remaining bugs go in the "1.0" milestone.

See the roadmap for a list of the must-have and maybe features:

   http://code.djangoproject.com/wiki/VersionOneRoadmap

I would like to stress the point that features not on the list are not 
to be put in any 1.0 milestone.  For those working on tickets for 
features or enhancements that are not on the list, please understand 
that these are lower priority than vetted features and *all* bugs.  If 
you really want to work on features not on the list, then keep track of 
them with some sort of "1.0dreaming" keyword instead of assigning them 
to a 1.0 milestone.

With 1.0 looming, this isn't the time to see how many features we can 
try to pack in, but rather time to focus on squashing all bugs.  I'm not 
here to tell you what you can and can't work on, but please keep the end 
goal in mind and help to focus efforts.

This e-mail was sparked by a couple ticket updates I noticed, namely 
#1061 and #3011.  Even if these sorts of features have a patch and are 
"Ready for checkin," that does not mean they get a 1.0 milestone.  They 
still take core developer time to review and commit, time that also 
needs to be focused on higher priority tickets.

Thanks,
Gary

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

[Gary Wilson Jr.]

Jacob Kaplan-Moss wrote:
> Help me out here: how can I make it more obvious?

Wow, you've certainly made it more obvious :)  I pity the fool that 
misses it now.

Gary

--~--~-~--~~~---~--~~
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: Paginator vs. QuerySetPaginator

[Gary Wilson Jr.]

Jeremy Dunck wrote:
> I just ran into the same issue several people before me have:
> Paginator is a bit dangerous when handed a queryset, and
> QuerySetPaginator should be used instead.
> 
> This ticket exists, but no core dev has contributed to discussion yet.
> http://code.djangoproject.com/ticket/7478
> 
> I'd like to avoid making it dangerously easy to consume memory/cpu on
> the full queryset.
> 
> isinstance(object_list, QuerySet) is a fairly straightforward way to
> collapse Paginator and QuerySetPaginator into a single class.
> 
> Are we not doing that because it'd mean importing django.db into a
> django.core object?
> 
> Is there some other way we can point the gun away from our foot?

I, for one, would be in favor of doing away with QueryPaginator and 
bringing back the behaviour of the _get_count() method of the lecacy 
ObjectPaginator:

def _get_count(self):
 # The old API allowed for self.object_list to be either a QuerySet or a
 # list. Here, we handle both.
 if self._count is None:
 try:
 self._count = self.object_list.count()
 except TypeError:
 self._count = len(self.object_list)
 return self._count
count = property(_get_count)

The legacy _get_count first tries to do object_list.count() with no 
arguments.  That raises a TypeError if object_list is a list, since 
list.count() requires an argument.  If the TypeError is raised, then 
_get_count falls back to using len(object_list).

Seems like this is a nice interface, either have your object_list 
provide a count() method or rely on len(object_list).  I believe this 
sort of duck typing would be better than an explicit type check.

Then, we would have no dangers when passing a QuerySet, no confusion as 
to which Paginator class to use, and the ability to accept any other 
"object_list" instance that has a count() method or can have len() 
called on it.

Gary

--~--~-~--~~~---~--~~
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: DDN: Contrib apps testing their own views (#7521)

[Gary Wilson Jr.]

Russell Keith-Magee wrote:
> On Wed, Jun 25, 2008 at 1:17 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
>> I can think of two options right now:
>>* manage.py test should not run django.contrib.* tests, those are
>> supposed to have been run in runtests.py and working fine (that's the
>> point of being a contrib app: django developers take care of it!).
>>* mange.py test should make sure that django.contrib.*.urls are
>> included and disable tests that would fail, or include such urls.
> 
> I'm not sure I like either of these options.
> 
> There is some value in having end users run tests for django.contrib -
> every person that runs the tests is one more person likely to spot
> (and report, and maybe fix) a problem. I'm not a big fan of making
> special cases, either.

Agreed.  I think manage.py test should run tests for all installed apps, 
no matter if they are contrib apps or not.

> My preferred solution here would be to provide a way for test cases to
> substitute a top level URL pattern object for the duration of the
> test. For example:
> 
> from django.tests import TestCase
> class MyTest(TestCase):
> fixtures = ['test.json']
> urls = 'local.test_urls'
> ...
> 
> The setup methods could swap in a temporary root URLconf, and swap it
> out again on teardown. The problem only exists for tests that need to
> poke views, so there isn't a huge need for a doctest analog, but the
> calls made by TestCase.setup/teardown could be abstracted into
> test.utils.

Swapping the root URLconf works, and is currently what contrib.formtools 
is doing.  Is your thinking that if a ``urls`` attribute is defined, the 
URLconf swapping in setup/teardown would be done for you?

Gary

--~--~-~--~~~---~--~~
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: URL Resolvers: a little refactoring goes a long way

[Gary Wilson Jr.]

Ken Arnold wrote:
> I wanted to get any feedback on this change before submitting a
> ticket, but if people think it's a good idea, I can clean up the patch
> and make a ticket.

Anything that gets REST projects and nfa off the ad-hoc dispatchers 
sounds like a good idea to me.  Along with a ticket and patch, it would 
be nice to see what nfa's dispatching looks like with the changes.  If 
you feel like it, please put those changes in the patch as well or 
attach a separate patch.

Thanks,
Gary

--~--~-~--~~~---~--~~
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: newforms generic views

[Gary Wilson Jr.]

Jacob Kaplan-Moss wrote:
> On Mon, Jun 16, 2008 at 3:51 PM, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote:
>>   a. I am thinking that we should instead keep the ``model`` argument,
>> but make it optional.  Then, we ensure that one of ``model`` or
>> ``form_class`` is given.  ``form_class``, if given, would override
>> ``model`` or if just ``model`` was given, then a ModelForm would be
>> created for the passed model.  Does this sound reasonable?
> 
> Yes, very much so. I'd like to call it ``model`` and ``form`` (instead
> of ``form_class``, which is redundant), but Brian's building the shed,
> so he can paint it any color he likes.

I assume that ``form_class`` was used because it actually needs to be a 
form class and not a form instance (the views take the form class and 
instantiate a form with the post data).  So I would say it should 
probably stay ``form_class``.

>> 2. What should we do with the ``follow`` argument?
> [...]
>>   b. We could issue a deprecation warning if ``follow`` is used,
>> letting people know that generic views now use newforms and to use
>> ``form_class`` if you need a custom form.  This would be a bit more
>> backwards compatible, since if you aren't using ``follow`` everything
>> should work the same.  If you are using ``follow``, then those forms
>> might display/behave differently (i.e. fields you were trying to hide
>> now get displayed).
> 
> +1 here. I'd say issue DeprecationWarning until 1.0 beta, then drop it 
> entirely.

Cool, this is what the current patch does.

> I'll have a look at the patch itself, but from your description it
> sounds like this is looking good.
> 
> Jacob

Gary

--~--~-~--~~~---~--~~
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: Experimental Git repository available

[Gary Wilson Jr.]

Marc Fargas wrote:
> El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió:
>> FWIW (I'm currently playing around with all three of them), bazaar
>> appears to support pushing into svn as well.
> 
> Yes, with bzr-svn.

Be advised, though, that currently bzr-svn will dump out a ton of svn 
properties into your repo [1].  Then, if you say to yourself "what the 
heck just happened!?" and go revert that revision (removing the 
properties), you will not be able to ever branch the repo again using 
bzr-svn until this bug [2] is fixed.  Wish I would have known that 
before I did it :)

Gary

[1] 
http://samba.org/~jelmer/bzr-svn/FAQ.html#bzr-svn-sets-all-kinds-of-file-properties-when-pushing-revisions-into-subversion-is-this-really-necessary
[2] https://bugs.launchpad.net/bzr-svn/+bug/174690

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

newforms generic views

[Gary Wilson Jr.]

I was taking a look at the latest patch [1] for #3639 (many thanks to
Brian Rosner for the hard work), and trying to decide how backwards
compatible we want to be.  (I should also mention that while there has
been some work done towards class-based generic views in #6735 [3], I
believe that #3639 should be completed first as #6735 could be done
post-1.0 if need be.)  So, I come to the community for input...

Currently the create_update views take a  required ``model`` argument
and an optional ``follow`` argument.  The ``model`` argument is fine and
we can carry that forward.  The ``follow`` argument, however, is
specific to oldforms Manipulators and was used for showing/hiding form
fields (see [2] for a refresher of the follow argument).

In order to enable custom newforms-style forms, Brian has added a
``form_class`` argument to the views, which I think is the correct way
to replace the functionality lost by the ``follow`` argument.

There are a couple design decisions that need to be made, though:

1. Brian's patch replaces the required ``model`` argument with the
required ``form_class`` argument, where ``form_class`` can either be a
``forms.ModelForm`` subclass or ``model.Model`` subclass.

   a. I am thinking that we should instead keep the ``model`` argument,
but make it optional.  Then, we ensure that one of ``model`` or
``form_class`` is given.  ``form_class``, if given, would override
``model`` or if just ``model`` was given, then a ModelForm would be
created for the passed model.  Does this sound reasonable?

   b. Anyone have any other ideas here?

2. What should we do with the ``follow`` argument?

   a. We could drop it completely, which would not be backwards
compatible for anyone using the ``follow`` argument.

   b. We could issue a deprecation warning if ``follow`` is used,
letting people know that generic views now use newforms and to use
``form_class`` if you need a custom form.  This would be a bit more
backwards compatible, since if you aren't using ``follow`` everything
should work the same.  If you are using ``follow``, then those forms
might display/behave differently (i.e. fields you were trying to hide
now get displayed).

   c. We could be even more backwards compatible by trying to take
fields declared in ``follow`` and make them includes/excludes in the
inner Meta class of the generated ModelForm.

I have taken Brian's latest patch and added implementations of 1a and
2b.  Other additions were:
  * Fixed an error I was getting in the tests when using "model = model"
in the inner Meta class (works fine in my shell, but gives me model not
defined errors when I run the tests) by introducing a tmp_model variable.
  * Added a GenericViewError class and made a couple AttributeErrors use
this Exception class instead since AttributeError didn't really fit.
  * Added a get_model_and_form_class helper function to remove duplicate
ModelForm-generating code.
  * Finished off the test_create_custom_save_article test with a
custom_create view that passes a custom form to the create_update
generic view.

I have attached my patch [4] to the ticket.

Gary

[1]
http://code.djangoproject.com/attachment/ticket/3639/create_update_newforms5.diff
[2] http://code.djangoproject.com/wiki/NewAdminChanges
[3] http://code.djangoproject.com/ticket/6735
[4] http://code.djangoproject.com/attachment/ticket/3639/3639.diff


--~--~-~--~~~---~--~~
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_{next,previous}_by_someDateField()

[Gary Wilson Jr.]

Marc Fargas wrote:
> m = TestModel()
> m.get_previous_by_date()
> 
> Will fail with an exception which says "Cannot use None as a query",
> maybe that error could be a bit more self-explicative, like "Cannot
> query next/previous items without being saved".

Agreed, please create a ticket for this.

Gary

--~--~-~--~~~---~--~~
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: extra() and values()

[Gary Wilson Jr.]

Nicolas E. Lara G. wrote:
> I was wondering if there was some sort of design decision on this or
> was just not implemented (yet).

I would say it just hasn't been implemented yet.

> Adding the fields to appear in the dictionary seams like an easy fix
> that
> I might do while working on aggregates but I'd like to know the
> feeling
> of the comunity on this.

Patches welcome, and please file a ticket so this bug is not forgotten.

Thanks,
Gary

--~--~-~--~~~---~--~~
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: Rethinking silent failures in templates

[Gary Wilson Jr.]

Jacob Kaplan-Moss wrote:
> On Sat, May 17, 2008 at 11:30 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>> The impression I get is that a lot of people rely on silent *variable*
>> failure, but very few rely on silent *tag* failure. In fact, most
>> real-world custom template tags I've seen are wired up to raise errors
>> quite loudly, and the few times I've tried to write tags which fail
>> silently it's been a laborious process that results in much more
>> brittle code.
> 
> Well said. I can't see making ``{{ foo.bar.baz }}`` fail loudly --
> it's just too big a change. It especially sucks when ``foo`` or
> ``bar`` is a dynamically-constructed dictionary with variable keys.

Yes, probably too big a change to make ``{{ foo.bar.baz }}`` fail loudly 
at this point (even though there are things like the default filter and 
the firstof tag that could facilitate such a change).

I would, however, be in favor for making the exception-catching a bit 
smarter here so that we don't suppress exceptions raised by a called 
method.  For example, I'm ok with:

{{ foo.calculate_number }}

failing silently if no calculate_number attribute/method exists for foo, 
but if calculate_number is a method and happens to raise an exception 
when called, I want that to bubble up and fail loudly.  Otherwise, 
hunting down the error becomes more of a chore.  Besides, the motivation 
behind the silent behavior seems to be more for missing attributes.

> I think taking a close look at built-in *tags*, though, is a good idea
> -- in general, tags should fail loudly. There are exceptions, of
> course; ``{% if dict.somekey %}`` is a common idiom which translates
> to something like ``if dict.has_key('somekey') and dict.somekey`` --
> this is good.

I also agree that, in many instances, tags should fail loudly, and that 
these types of failures need to be looked at on a tag by tag basis.  The 
question then becomes, do we want to always raise these exceptions or do 
we want to only raise them if settings.TEMPLATE_DEBUG is True?

Gary

--~--~-~--~~~---~--~~
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: Partial Models Discussion

[Gary Wilson Jr.]

David Cramer wrote:
> IMO show() and hide() are extremely ugly. And I think .values() is becoming
> ugly with the addition of values_tuple or whatever it's called. I don't see
> a real good reason to clutter the namespace even more than it already is.
> I'd rather have .values(type=dict) or something similar.

Sorry, for some reason I completely skipped over the type switching in 
the values() call.  I do agree that it would be better than having 
separate methods for each.

I wonder if we would also need to support the people who want to exclude 
fields:

Model.objects.values('field1', 'field2', exclude_fields=[...], type=...)

Has a discussion of something like the "type" keyword argument been 
brought up before?  The only two threads [1][2] I found about 
valuelist() and value_list() don't mention the idea.

Gary

[1] 
http://groups.google.com/group/django-developers/browse_frm/thread/22b44f4eafaf956a/
[2] 
http://groups.google.com/group/django-developers/browse_frm/thread/4c7ba291577e6e73/

--~--~-~--~~~---~--~~
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: Want to have unit tests in multiple files

[Gary Wilson Jr.]

Alex Koshelev wrote:
> No. Not `tests.py`, but `tests` module - that can be a package of many
> other modules/files

In case you haven't figured this out already, it can be done by 
importing your unit test classes from the test/*.py modules in 
tests/__init__.py

Gary

--~--~-~--~~~---~--~~
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: Bug (very mild) in PostgreSQL version _check_

[Gary Wilson Jr.]

Haroldo Stenger wrote:
> I think I've found a bug in Django and a solution :-)

Please file a ticket [1] (after searching first [2]) for this issue if 
you haven't already so that it's not forgotten.

[1] http://code.djangoproject.com/simpleticket
[2] http://code.djangoproject.com/query

Thanks,
Gary

--~--~-~--~~~---~--~~
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: Generative values() Does not Work

[Gary Wilson Jr.]

Russell Keith-Magee wrote:
> 
> On 31/03/2008, at 2:33 AM, mtrier wrote:
> 
>> Before opening a ticket I thought I would check what the expected
>> behavior is for generative values().  This is the behavior I'm seeing
>> on Queryset Refactor branch and to me it seems like it is not the
>> correct behavior.
>>
> from original.foo.models import Category
> Category.objects.all()
>> [, , , > CSharp>]
> Category.objects.values('name')
>> [{'name': u'Algol'}, {'name': u'Smalltalk'}, {'name': u'PHP'},
>> {'name': u'CSharp'}]
> Category.objects.values('name', 'id')
>> [{'name': u'Algol', 'id': 1}, {'name': u'Smalltalk', 'id': 2},
>> {'name': u'PHP', 'id': 3}, {'name': u'CSharp', 'id': 4}]
> Category.objects.values('name').values('id')
>> [{'name': u'Algol'}, {'name': u'Smalltalk'}, {'name': u'PHP'},
>> {'name': u'CSharp'}]
>>
>> It would seem to me that the last query should return the same thing
>> as the prior one.
> 
> Agreed. This looks like a bug to me; at a guess, the problem will be  
> that when ValuesQuerySet is cloned, it doesn't copy the attribute list.

I also agree that this is a bug, as the "first one wins" behavior displayed 
above is not intuitive.  But what should the desired behavior should be?

The OP suggests an additive behavior similar to the way filter()
operates.  However, there is also the option of a "last one wins" approach, as
seen by the order_by() method (on trunk, is it the same in qs-rf?):

>>> User.objects.order_by('last_name')._order_by
('last_name',)

>>> User.objects.order_by('last_name').order_by('first_name')._order_by
('first_name',)

>>> User.objects.order_by('last_name', 'first_name')._order_by
('last_name', 'first_name')

If I had to pick a behavior, I guess I would lean towards the "last one wins"
approach.  order_by() and values() are methods that I typically use towards
the end of my QuerySet constructions, and if I'm passed a QuerySet from some
other code I would like my order_by() or values() to take precedence.

Gary

--~--~-~--~~~---~--~~
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: Pick a value from list variable in templates

[Gary Wilson Jr.]

Yuri Baburov wrote:
> I don't like the point of view that "everyone has his own library",
> because it's too childish. It isn't a solution at all, it's just a
> despair after attempts to find a good enough solution.
> You did a great thing inventing simple and useful ORM, good template
> language, lots of other great stuff.

I think comparing a single template filter to something as big as the ORM is a 
bit unfair.  A simple filter takes minutes to create, an ORM on the other hand 
is not so simple.

> But I'm wondering why you are willing to refuse inventing more right things?
> Remember one of you said that Django is a collection of simple things
> useful in practice?
> What's the price of philosophy if it's stopping from creating
> practically useful things?

Django is your _framework_ for building the useful things.  While it may not 
contain everything you need, it should certainly provide a way for you to 
quickly and easily create the things you need.

> As I see the process, this thread is one where brainstorming is going on.
> After that you, dear core developers, choose the best one.

I say let the brainstorm pour.  If the developers see something they like, 
they will let the community know.  It's pretty clear, though, that the 
developers aren't in favor of adding any new syntax, and aren't very fond of 
including too-non-programmer-friendly template features.

In many instances, there are ways to move the complexity out of the templates 
and into the code.  This is a big reason why the template language is so 
limiting, as it forces you to put the complexity in the code where it should 
be.  I have no idea what sort of situation the OP is in since there was not a 
lot of information about what's going on around the proposed template filter 
code, but maybe instead of:

{{ myModel.getLocalizedNames|pick:userLanguage }}

something less complex could be used:

{{ user.get_localized_name }}

or maybe the view could pass the localized name:

def view(...):
 ...
 name = myModel.getLocalizedNames[userLanguage]
 return render_to_response(..., {'name': name})

> We don't need to find ideal solution (cause it might not exist), but
> the one, that is good enough, that is worth adding to Django.
> From my side, I realize that I need such thing in templates.
> From my side, I'd like to see one good enough thing doing this job to
> be included in Django.
> I don't want everyone to create their own solution of this problem.
> In my current work I see up to 10 small projects written by 5 different 
> people.
> Do you think it's good to see everyone using their own libraries that
> does such simple thing?
> And what about libraries? Should they also create their own
> templatetag for this?
> I'm begging you, please, please, find a good enough decision to
> include in django core.

You don't _have_ to resort to writing your own library, I just think that most 
people end up doing that because it's faster sometimes.  For those who need 
and use a lot of list operations in templates, it might make sense to join 
together and start a django-template-listutils project.  You could could take 
all the list-related template tags and filters that already exist in Django 
and add to it other useful ones.  Anyone who needs the special list template 
filters can all use and support the same code.  Then, the next person who 
comes along wanting such a feature won't have to write their own library, they 
can use the existing one.

There are several great Django projects out there that started with one or 
more people getting together to solve a common problem.  Is Django wrong for 
not including them in it's codebase?  Certainly not, but that does not make 
those projects any less useful or any less popular.

Gary

--~--~-~--~~~---~--~~
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: Class based generic views

[Gary Wilson Jr.]

Joseph Kocherhans wrote:
> I just uploaded a patch [1] for class based generic views that use
> ModelForm internally. Personally, I think this makes the generic views
> a lot more flexible, and gives us a great argument against
> adding-yet-another-config-argument-to-generic-views (even though I
> haven't heard that particular demand come up for awhile.) Just
> subclass the generic view, and do what you need.

I like the flexibility that the class-based approach brings.  I think a 
similar idea could be used to clean up the duplication happening in the date 
based generic views.  Anyone know if that has been attempted?

> Anyhow, here's what I have in mind for the backwards compatibility story:
> 
> This patch leaves the old generic views as-is, using manipulators.
> This partially fixes the problem, we get ModelForm based generic views
> living side by side with the old manipulator based ones. People can
> svn up without breaking anything, and convert their code at their
> convenience. At some point I think we'll want to either get rid of the
> old functions, or convert them to use the new classes (should be
> trivial). Personally, I'd rather do the former, but I'm probably in
> the minority there.

I'm with you on keeping them side-by-side and then removing the 
manipulator-based views when we take out oldforms.

Gary

--~--~-~--~~~---~--~~
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: Feature Request: small extension to mod python authentication handler

[Gary Wilson Jr.]

[EMAIL PROTECTED] wrote:
> Hi,
> 
> I'd like to use django for authentication in apache, and it would be
> nice to have group based access.
> Therefore i did a little patch to django/contrib/auth/handlers/
> mod_python.py
> 
> group = options.get('DjangoRequireGroup', None)
> ...
> if group:
> kwargs['groups__name'] = group
> 
> So i'm able to put something like
> PythonOption DjangoRequireGroup somegroup
> into my apache configuration
> 
> I'd like to hear some opinions if thats a good idea.

Sounds like a decent idea to me, but you should really file a ticket for this
so it won't be forgotten.  Attaching your patch to the ticket would be a good
idea too.

Gary

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

anyone against me checking in #5422 - raw parameter for pre/post_save signals

[Gary Wilson Jr.]

It's needed for the same reasons that the Model.save() method needs it. 
  When loading fixtures, you sometimes don't want to touch the incoming 
data.

For example, if I have a simple function connected to a pre_save signal 
that updates a timestamp:

def update_timestamp(instance, **kwargs):
 # Update the timestamp if we aren't loading from a fixture.
 if not kwargs.get('raw'):
 self.timestamp = datetime.now()
 return super(MyModel, self).save()

Without being able to check for raw, the update_timestamp would alter 
the timestamp dates from my fixture.

It looks like this change would be backwards-compatible because 
django.dispatch.robustapply.robustApply checks to see what arguments and 
keyword arguments the receiver accepts and only calls the receiver with 
those arguments.

Gary

--~--~-~--~~~---~--~~
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: middleware exception catching for core handlers

[Gary Wilson Jr.]

Karen Tracey wrote:
> Can't answer as to why it is the way it is, but Gary did open a defect to
> track the issue, and it has a patch:
> 
> http://code.djangoproject.com/ticket/6094
> 
> Someone else a couple of weeks ago opened another couple of defects covering
> the same issue, and when pointed to the first defect updated the patch to
> apply cleanly against (then-current) trunk.  So there's a patch to try and
> report results of, if you like.  No one has piped up to say why this
> shouldn't be changed, so I'd guess it's just waiting on someone with enough
> expertise and time to give it some attention.

I was mainly waiting for review and some testing.  Malcolm has now reviewed
it.  I have not tested it in a ModPython setup yet.  So please, test and note
your results here.  I've just added an updated patch to the ticket, enjoy.

Gary

--~--~-~--~~~---~--~~
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: lazy (in utils.functional) is broken

[Gary Wilson Jr.]

SmileyChris wrote:
> I've been working on a new version of the session messages ticket and
> was looking at making the "messages" context variable lazy - it seems
> silly how it currently wipes messages, even if you didn't check for
> them.

What ticket number is this btw?

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

middleware exception catching for core handlers

[Gary Wilson Jr.]

We don't seem to be catching exceptions raised in response or request 
middleware, causing bare exceptions to be displayed.  Is there a reason 
we are not catching these and displaying pretty error pages?

Which leads me to another observation.  There seems to be a bit of 
duplication in the WSGIHandler/ModPythonHandler and 
WSGIRequest/ModPythonRequest classes.

Gary

--~--~-~--~~~---~--~~
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: queries, Nones and NULLs

[Gary Wilson Jr.]

Michal Salaban wrote:
> Anyway, seems that any query with field=None just doesn't make any
> sense and, if used by anyone, is meant to do the same as
> field__isnull=False. Wouldn't it be a good idea to convert such
> queries to field__isnull=False equivalent in Model class? Correct me
> if I'm wrong, please.

You are not alone in your thinking.  See the latest django-dev thread on 
this issue:

http://groups.google.com/group/django-developers/browse_frm/thread/d52d9882db719266/

FYI, the ticket on this is here:

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

Gary

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