metrics: Django case study

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.

Re: auth.User refactor: reboot

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

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

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

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

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

safe characters used in iri_to_uri (#12445)

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 = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

Re: Summer of Code: mentors wanted

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

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

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

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

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

Re: Call for review: #689 - REMOTE_USER authentication

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

Call for review: #689 - REMOTE_USER authentication

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

Re: Option to disable messages in auth context processor

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

Re: Dropping Python 2.3 compatibility for Django 1.1

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

Re: Last call for 1.0 alpha

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

Re: Reminder: "Must-have" feature freeze in two weeks

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

tickets and use of the 1.0 milestones

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

Re: Spam detection

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

Re: Paginator vs. QuerySetPaginator

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

Re: DDN: Contrib apps testing their own views (#7521)

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

Re: URL Resolvers: a little refactoring goes a long way

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

Re: newforms generic views

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

Re: Experimental Git repository available

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

newforms generic views

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

Re: get_{next,previous}_by_someDateField()

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

Re: extra() and values()

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

Re: Rethinking silent failures in templates

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

Re: Partial Models Discussion

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

Re: Want to have unit tests in multiple files

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

Re: Bug (very mild) in PostgreSQL version _check_

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,

Re: Generative values() Does not Work

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

Re: Pick a value from list variable in templates

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 >

Re: Class based generic views

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

Re: Feature Request: small extension to mod python authentication handler

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

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

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

Re: middleware exception catching for core handlers

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

Re: lazy (in utils.functional) is broken

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?

middleware exception catching for core handlers

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

Re: queries, Nones and NULLs

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