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
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 trans
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/t
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 uns
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 = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
unrese
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://socgh
On Sun, Mar 15, 2009 at 4:40 PM, Malcolm Tredinnick
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 throu
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 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 ad
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 djan
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
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 time
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
--~--~
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
dup
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 thi
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
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/tic
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
>> poin
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 ticke
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
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 sv
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
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
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 aggregat
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 wire
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 someth
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
--~--~-~--~~---
David Cramer wrote:
> I'd like to present my concept for partial models, which would be an
> attempt to replace the use of .values() returning a dictionary
> (although .values() still has uses if you dont actually want an
> instance). Keep in mind, the way I'm presenting this would keep #17
> work
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,
G
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
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,
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
>
[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:
>
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):
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
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?
--~--~-~--~
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 WSGIH
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 wr
38 matches
Mail list logo