SmileyChris wrote:
> I know this would be backwards incompatible, but why on earth do our
> newform clean_[fieldname] methods need to get the value out of the
> self.cleaned_data dict. It just seems so un-DRY.
This irritates me too. I'm +1 for passing the value, as noted by my
patch attached to
I know there are various setups people have for doing this, like Jacob's
snippet:
http://www.djangosnippets.org/snippets/106/
but I was wondering what other developers' thoughts would be on adding
something like this to Django proper. I'm just thinking that Django
should be able to test itself
Malcolm Tredinnick wrote:
> I want to hear the use-case first. I may change my mind, but nobody's
> come up with a good reason so far.
How about looking at things from the opposite direction? Yes, it would
be nice if the Django template system could be more easily used
standalone, but by doing t
Brian Harring wrote:
> While reordering the bug flow is a good thing, I'm not really sure
> about the gain of it. Basically, better tools/flow doesn't mean
> faster resolution/commits- just means it's organized better. A weekly
> email *would* be nice, but view it as a stopgap approach to try
Gary Wilson wrote:
> I agree with all the points you make here, Brian. We revamped the
> ticket process a few months ago and I think any further changes is going
> to give us diminishing returns.
Oh, I forgot to mention something about possibly introducing a bug day.
It's alway
Brian Harring wrote:
> So... thoughts? The second round of refactoring posted on 5106
> currently lacks some of the new features mentioned above (need to port
> them over mainly), but v3l address that, and add in at least a
> SteadyDB persistant connection (pooling would be based off that). T
Malcolm Tredinnick wrote:
> On Mon, 2007-08-13 at 18:00 -0700, sime wrote:
>> 1. Magic cleaned_data - So we can get/set values out of order and
>> before the clean() run, having themselves clean implicitly as
>> required.
>
> Can you give an example of what you mean here? I can't visualise what's
Marty Alchin wrote:
> On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>> This would let projects like S-E -- there's a reason I used it for the
>> example -- provide custom management actions; installing said app
>> would make those actions "appear" in manage.py. This would go a long
>> w
On Jul 16, 4:19 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 7/16/07, David Cramer <[EMAIL PROTECTED]> wrote:
> > Is there a specific reason that myfield=Nonedoesn't translate to
> > myfield__isnull=True in the database backend?
>
> The reason is in the implementation details, but, come t
On Aug 17, 12:16 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> And I just realized I missed #3134, which argued for a slightly
> different solution, in the form of an 'order_by' parameter to the
> views.
>
> Personally, I think it's easier to just skip the parameter and rely on
> the fact that
Malcolm Tredinnick wrote:
> On Mon, 2007-07-16 at 02:19 -0500, Jeremy Dunck wrote:
>> I just ran into a subtle backwards incompatibility introduced in [5091].
>>
>> I've been pushing an instance of xml.sax.xmlreader.AttributesImpl onto
>> my Context. AttributesImpl tries to implement a dictionary
SmileyChris wrote:
> On Aug 30, 11:47 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>> On Thu, 2007-08-30 at 19:01 +0800, Russell Keith-Magee wrote:
>>> On 8/30/07, SmileyChris <[EMAIL PROTECTED]> wrote:
It has always made me wonder why it isn't even overridable. Is there a
design
Russell Keith-Magee wrote:
> On 8/30/07, George Vilches <[EMAIL PROTECTED]> wrote:
>> Now that the database backend refactoring has landed, and DB
>> functionality is really easy to extend, how does everyone feel about the
>> possibility of allowing people to specify their own database backends
>>
bringing discussion to the list...
For testing purposes, I was thinking it would be nice to have a way to assert
the value of a context variable used to render a response. So I created
ticket #5333 [1], where I proposed add an assertContext method to Django's
TestCase class with the following si
Gary Wilson wrote:
> Russell then added the comments:
> -
> My hesitation here (and the reason I didn't include a 'context assert' in the
> first place) is that assertContext does an Equals test, but doesn't provide a
> way to do any other assertion
On Sep 5, 3:32 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I propose Friday, September 14. Some reasoning:
Count me in. Maybe even some spillover into the weekend while at the
Texas Python Regional Unconference [1].
Gary
[1] http://pycamp.python.org/Texas/HomePage
--~--~-~--~-
Marty Alchin wrote:
> So, just so I'm clear, is this for everybody, or just the core
> developers? For instance, I'm actively maintaining the new filestorage
> mechanism for the time being, so should I accept that as my own?
Everybody and yes.
Gary
--~--~-~--~~~---~-
Russell Keith-Magee wrote:
> On 9/5/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> Gary Wilson wrote:
>>> Russell then added the comments:
>>> -
>>> My hesitation here (and the reason I didn't include a 'context assert' in
>
Any other core devs have an opinion about using a MultipleObjectsReturned
exception (or call it what you want) instead of an assert statement in
QuerySet.get()?
IMO, this would make things a bit cleaner and compliment DoesNotExist nicely.
Original discussion was here:
http://groups.google.com/gr
Collin Grady wrote:
> David Cramer said the following:
>> I don't believe .create() allows you to say myforeignkey=1, correct me
>> if I'm wrong, but I think it throws an error about it needing to be a
>> instance.
Yes, you are correct.
> But .create() already works with fkeyname_id, it's just
Yuri Baburov wrote:
> Do you need more committers/triagers?
Yes, always. This has been discussed, and we will promote those who deserve
it. For those wanting to know how to become committers or triagers, well, I
can tell you how I did it:
1. Spend lots of time using Django.
2. Take part in ma
Yuri Baburov wrote:
> For me, the process of developing Queryset refactoring totally went
> out of control. And everyone says that "all will be outdated after
> queryset refactoring release so we won't do anything now."
As mentioned by someone else in this thread, this is partly due to not wantin
So last night I checked in changeset 6391, and this morning it hit me that
this breaks things for anyone using the admin application at more than one URL
since the url tag cannot handle cases where multiple instances of an
application are being used. This may not be as big an issue for the curren
George Vilches wrote:
> All,
>
> Just throwing this out there because I think it breaks everyone
> currently using sessions against trunk. Already filed a ticket (and
> patch) for it: http://code.djangoproject.com/ticket/5598 .
Fixed in http://code.djangoproject.com/changeset/6425
Thanks for
SmileyChris wrote:
> [6506] fixed #5744.
>
> Do we still need django.newforms.forms::SortedDictFromList?
Nice catch, it indeed looks like SortedDictFromList is no longer needed.
> The only thing which the newforms code has extra is its own copy
> function which uses deepcopy. I'm at a loss to s
Russell Keith-Magee wrote:
> On 10/13/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>> I know the argument list for form_for_model is getting long, but
>> excluding fields is just so damn useful ;)
>
> +1 from me. Personally, I'm in favour of making form_for_model as
> flexible as possible.
I
Is there a reason why setup_environ adds the parent directory of the project
directory to the path, imports the project module, and then removes the parent
directory from the path? The imported project module is also not used
afterwards.
--~--~-~--~~~---~--~~
You
Charles wrote:
> I've installed Django v.0.96 on an Ubuntu Linux 7.10 system and am
> going through the tutorial available at the Django site. The latest
> error popped up when I tried to run the admin app. The current error
> is:
>
> ImproperlyConfigured at /admin/
> Module "django.template.load
SmileyChris wrote:
> It seems silly that currently the auth message system calls
> get_and_delete_messages for every request context (assuming you have
> the auth context processor enabled, like it is by default).
>
> 1. You lose messages if you don't actually check for them
>
> 2. If you didn't
Alexander Solovyov wrote:
> But lets' listen what core developers think about making this the
> official way. :)
Personally, I like the idea of being able to switch out User models, as long
as a base interface can be worked out. It seems that there might be a few
people using a version of a patc
Malcolm Tredinnick wrote:
> I do agree with Chris, though. It's completely unrelated to
> auto-escaping (which will land today, most likely, since I've been
> merging it and updating it yesterday and the day before).
w00t!
> Not sure if we should build it into admin or make the middleware a
> re
Jeremy Dunck wrote:
> On Nov 13, 2007 10:02 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>> Personally, I'm comfortable with documenting the fact that if
>> Model.save() is never called, the pre_save and post_save signals will
>> never fire (same is true of overridden __init__() and the post_init
James Bennett wrote:
> On 11/13/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> How about introducing pre_save and/or post_save methods. The signal firing
>> happens in pre_save and post_save. You can override whatever you want -
>> pre_save, save, or post_save dep
Joseph Kocherhans wrote:
> Hey Todd, I haven't looked at you patch, but here's what Russ
> mentioned when I asked:
>
> http://groups.google.com/group/django-developers/browse_thread/thread/fb148adb454b74ef/789da4389cf33295?lnk=gst&q=kocherhans+django-admin#789da4389cf33295
Would it be crazy if w
Collin Grady wrote:
> Are you seeing this behavior in admin? If so, I believe that is what is
> actually at fault, since it hard-sets m2ms, which would clear anything
> set in save().
I know Russ didn't take much of a liking to this idea last time I mentioned
it, but...
That's why I say this fun
Gary Wilson wrote:
> Is there a reason why setup_environ adds the parent directory of the project
> directory to the path, imports the project module, and then removes the parent
> directory from the path? The imported project module is also not used
> afterwards.
Adrian,
Jacob Kaplan-Moss wrote:
> Oh yeah, and one other thing:
>
> IANAL, but I think the Python Software License is not compatible with
> the BSD, so we'll need permission from the PSF to distribute code
> copied from functools.py, and we'll need to include the original
> copyright statement.
Any hea
Adrian Holovaty wrote:
> Without further ado, here's my list:
>
> * newforms-admin
> * queryset-refactor
> * django.newforms becomes django.forms
> * Model-level validation
> * Change django.templatetags not to use __path__ hacking
> * #3591 -- Make INSTALLED_APPS an instance, and each app an ins
Adrian Holovaty wrote:
> On Dec 2, 2007 11:50 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>> I guess I'm curious as to what's difficult or error-prone about it;
>> I've never run into a problem where slicing was the cuplrit, and it
>> feels like a more intuitive and Pythonic syntax than the "limi
Is there any reason why the following is disallowed:
>>> UTPerson.objects.all()[:10].filter(name__startswith='a')
Traceback (most recent call last):
...
AssertionError: Cannot filter a query once a slice has been taken.
I would think that it should be possible as long as the QuerySet hasn't been
It is recommended to evaluate a QuerySet by calling list() on it. Problem is,
now you have a list and not a QuerySet. Just thinking it might be nice to
have an evaluate() method that would return a QuerySet object with the result
cache filled.
Now, if only I could think of a use case ;)
Gary
Malcolm Tredinnick wrote:
> Anybody have strong objections to ticket #5524: not completely nuking
> form.cleaned_data is a form instance has any non-zero validation errors?
No objections here, seems like the Right Thing to do. My data was cleaned,
keep it that way.
Gary
--~--~-~--~
Derek Anderson wrote:
> even if it was possible, i don't think it's what you would really want.
> logically, this would return an indefinite number of records,
> somewhere between 0 and 10, depending on what's in your table, not the
> first 10 records of people who's name starts w/ an 'a'.
Luke Plant wrote:
> On Tuesday 04 December 2007 07:25:31 Gary Wilson wrote:
>
>> Sort of my point. Since filter() and [:] both return QuerySets why
>> should they be any different:
>>
>> UTPerson.objects.all().filter(name__startswith='a')[:10]
>
&g
Adrian Holovaty wrote:
> On Dec 4, 2007 12:57 AM, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> But what would the situation be with a new limit() method...
>>
>> objects = MyModel.objects.filter(site=1)
>> first_one = objects.limit(1)
>> do_something_special(
I've attached a patch that does the following:
* Added a `handle_response` method to `BaseHandler` to factor out duplicated
code in `ModPythonHandler`, `WSGIHandler`, and `ClientHandler`.
* Replaced `resolver` temporary variable with a `resolver` method to ease
refactoring of `get_response` met
Vinay Sajip wrote:
> On Dec 7, 6:35 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>> On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>>
>>> this be allowed/disallowed/checked for? As for standard template
>>> loading, there's no reason that the standard template loading
>>> (app_lo
Peter Baumgartner wrote:
> http://code.djangoproject.com/ticket/3511 broke some code I had that
> caught AssertionError in the past. Seems like it should be listed on
> http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges
done.
Thanks,
Gary
--~--~-~--~~~--
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 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
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
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
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
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
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
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
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:
> 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
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
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
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
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
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
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:
> 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
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
--~--~
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
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
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 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
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 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
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
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
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
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?
--~--~-~--~
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
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):
[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:
>
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
>
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,
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
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
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
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:
> 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
201 - 286 of 286 matches
Mail list logo
