Re: 1.2 Proposal: django debug toolbar in contrib
Hey Idan -- On Mon, Aug 17, 2009 at 7:21 AM, Idan Gazit wrote: > I've been working on prettyfication of the DDT. Github: > http://github.com/idangazit/django-debug-toolbar/tree/idan-ui-rf. It's > a reasonably complete reskinning of the existing DDT. There are still > a couple of outstanding issues but the redesign is largely finished. Looks nice enough to me! > I didn't use the admin color palette because A) it's fugly and B) I > think making the DDT consistent with an optional-and-completely- > separate-contrib-tool is synthetic and meaningless. I'd disagree with (a), but, well, taste has no taste. However, I completely agree with (b) -- in fact, there's precedent for making developer-facing UI different: see the pretty error pages and the "it worked!" page, which aren't Django branded in any way. The reasoning was that we wanted the error pages to be somewhat framework-agnostic; we didn't want to impose our branding onto parts of *your* site. I'd say a similar ethos should be expressed in the debug toolbar branding. If you wanted to be extra special, some UI similarity between the error pages and the debug toolbar would probably be a good idea. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ticket #7539 (ON DELETE support) in Django 1.2?
Hi folks -- Y'know, there's quite a bit of bike-shedding going on in this discussion, and not a whole lot of code writing. Remember that our general policy is that whoever builds the shed gets to paint it; y'all might want to spend some of this energy actually working on a patch. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: Better way to extend user table
Hi Jonas -- On Mon, Aug 17, 2009 at 7:43 AM, Jonas Obrist wrote: > Basically it lets you define a class in settings which extends the User > table before it's created, using subclassing. This is a non-starter. It's not going to happen. Back in the day, Django actually had this "feature." There was a Meta option called "replaces_module" which did this: it reached in and replaced another model with the one you provided. If you do some googling for "replaces_module" you'll see it described as "hacky," "broken," "incredibly ugly," and other such complimentary terns. That's because while the *idea* of reaching in and replacing another model *sounds* like a good extension hook, in practice, it's nearly a cardinal sin. It means that if you make a change to the overridden model, that change doesn't show up -- because it's been overridden. It means that simply reading the model code isn't enough -- because something, somewhere, "might" replace it. Worse, it completely breaks the idea of a common utility module. If your app defines a user replacement, and my app defines a different one... we can't share code any more. Django's raison d'être is to facilitate application reuse; monkeypatching of any sort greatly hampers that. I appreciate that the user class isn't appropriate for everyone. But monkeypatching it isn't the solution. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature proposal: admin.ModelAdmin modified hook
On Mon, Aug 17, 2009 at 9:10 AM, Joshua Russo wrote: > I will try hooking into both post_save and post_delete signals though I was > looking for a more unified approach, to avoid repetition. You may already know this, but you can hook the same method up to multiple signals:: def handle_save_or_delete(sender, **kwargs): ... post_save.connect(handle_save_or_delete) post_delete.connect(handle_save_or_delete) That's your save-or-delete signal, right there. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: JS library in admin and tools
Django is a server-side framework. It should never dictate front-end considerations. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: JS library in admin and tools
On Tue, Aug 18, 2009 at 12:35 PM, Yuri Baburov wrote: > Do you think that using *any* javascript framework for admin interface > will get boost for useful admin, overall django improvements and > third-party plugins development? That's a different question entirely. The admin's an optional *application*, not part of the framework-y parts; it's also designed for end-users, not other developers. Data entry clerks aren't constrained by a choice of tooling in the admin interface the way developers would in the framework as a whole. Indeed, if you look at the admin-ui SoC project you'll see that this ship has already sailed: the new features added there (and, Murphy willing, to trunk soon enough) are indeed using jQuery. > Maybe some library-agnostic helpers? I don't think this is possible. > At least $() instead of document.getElementById() Here you go: ``var $ = document.getElementById;`` Enjoy. > Or kind of "django-jquery-helpers" sort of third-party addons? This has already been done at least a few times: see django-helpers, dojango, etc. > How do you see further django-and-js-related infrastructure in future? Heh, you give me far too much credit. I'm a here-and-now kind of guy. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: JS library in admin and tools
On Tue, Aug 18, 2009 at 2:04 PM, Alex Gaynor wrote: > I'll take a Jacob's comment a step further and say that I personally > am opposed to Django using an external JS framework for even the > admin. My reason for this is that it restricts the ability of people > to contribute to Django. Heh. Well, then let's table this discussion for when I propose merging admin-ui to trunk. Let's not get into a hypothetical argument when there's a perfectly good concrete one just down the road! Putting-on-my-flame-proof-pants-ly yours, Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: JS library in admin and tools
On Tue, Aug 18, 2009 at 2:36 PM, Yuri Baburov wrote: > How Django will/would package jQuery? That one for admin-ui. Like I said, let's table this discussion until there's actually something specific to talk about. Otherwise this is all just hand-waving, and I do enough of that anyway. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time frame for GSoC projects integration
On Fri, Aug 28, 2009 at 2:35 PM, James Bennett wrote: > There is no timeline I'm aware of. And, personally, I don't think > there's a need for any sort of special process: these are pieces of > work which can be proposed for inclusion in Django just like anything > else. That's generally my feeling as well, but I'd like to in the near term get a feel for how close the SoC projects are to merging. In particular, I'd like to make 1.2 include all the mergeworthy SoC code, but I don't have a feel yet for how realistic that's going to be. There's going to be some (possibly complex) timing issues w/r/t merge conflicts between different branches, so doing things in the right order might become important. I'm going to be emailing students/mentors in the next couple-three days and trying to work out a loose gameplan here. However, James is completely right that there's not a big difference between this work and other stuff. IOW, the best way to make sure that SoC code gets back into Django is same as it ever was: use it, file bugs, patches, and when it's done tell us. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Moving the Django Project to a DVCS
On Fri, Sep 11, 2009 at 8:36 PM, Jared Kuolt wrote: > I propose that the core team set a timeline to resolve this, one way > or another, with input from the community. If we could agree on a common server format that let anyone use any DVCS they chose on their personal machines, then we'd get the best of both worlds: a centralized master repo with all the benefits therein, alongside DVCSes of choice without the need to choose a winner. Oh wait, we've got a master server format. It's called "SVN." I see no good reason to change it, and many bad ones. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Replacing get_absolute_url, I am against it
On Sat, Sep 12, 2009 at 8:42 AM, Thomas K. Adamcik wrote:
> In essence we could add only one new method to the API that returns a
> URL-object that provides access to the data:
I like this idea a lot. It solves most of the problems I have with
get_absolute_url:
* I dislike the name -- far too verbose. Why not just `obj.url()`?
* I wish there was a better mechanism for getting host-relative URLs,
schema-relative URLs, etc. The `` trick is annoyingly
obscure.
* The mismatch between `...@models.permalink` and `get_absolute_url` is
very counter-intuitive.
* The fact that the returned URL is a string often means I end up
doing something like `obj.get_absolute_url().split('/')`. Objects are
better.
> If reverse() and {% url %} methods are updated to use such an URL-object
> backwards-compatibility can probably be persevered through a proper __str__
> method on the URL-object.
Python's already got such an object; it's `urlparse.ParseResult` (the
object returned by `urlparse.urlparse`. We'd need a tiny subclass with
a backwards-compatible `__str__`, but that's about it.
> I have not double checked if all the issues mentioned in
> http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl can be solved with
> such a scheme, but if there is interest in such a solution I'm willing to look
> into this and trying out the idea either as an external project or as a patch
> proposal.
I'm +1 on this proposal; please ping me if you work up a patch and
I'll take a look.
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
SoC merge plans?
Hi folks -- I'd like to start thinking about merging the SoC branches. As far as I can tell we've got solid, worth-merging work out of all six of 'em -- WOOHOO! -- so let's cracking getting this stuff to trunk so people can play with it. I'd like to ask each mentor/student pair to give me a bit of information: * A quick summary (more for the list than for me) of what new things are on the branch, and give some instructions to people wanting to review your code. * A detailed explanation of *any* backwards-incompatible changes merging your branch would make. * Are all the technical aspects of your house in order? Is what's on the branch at about the same level as we'd require from a patch (tests passing, APIs complete, documentation included)? If not, what's left to be done in this department? * Is it going to be better to merge bits off the branch piecemeal, or should we plan to merge the whole dang thing? * Are there any other branches you're worried about comparability with? Or any other sort of sequencing concerns we should take into account? I'm going to be reviewing the branches looking for these sorts of things, and I'm going to try to work up a merge plan over the next week or so. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Replacing get_absolute_url, I am against it
On Sat, Sep 12, 2009 at 6:19 PM, Ivan Sagalaev
wrote:
>> In the rare cases when I do need to split a URL into parts I just use
>> urlsplit:
>>
>> schema, domain, path, query, fragment = urlsplit(obj.url())
That's not in any way intitutive for a new user in the way that
`obj.url().schema` is.
> Oh... And for template authors we could just make 5 filters returning
> those parts:
>
> {{ obj.url|domain }}
So we need *five* new built-in filters instead of `{{ obj.url.domain
}}`? Why? What if I want to access the username or password? Do we
"just" add two more filters?
Ugh.
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Replacing get_absolute_url, I am against it
Hi guys -- Ya know, this conversation is going in circles, and arguing over increasingly trivial details. As always, our policy is that the person who builds the bikeshed gets to decide which color it is, so I'd suggest we all stop writing email and start writing Python now. Work up a patch, and then let's discuss from there. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch Review - #9638
On Thu, Sep 17, 2009 at 9:26 AM, lakin wrote: > Does anyone have the time to review the patch, please? Looks good; I've marked it ready for commit. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #9886: HttpRequest refactoring
On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev wrote: > Ticket [9886] is one of the things that I've been holding for 1.2 time > frame to ask for some discussion since Jacob marked it DDN. At first glance, you need docs and tests before you get a second glance :) Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Question on ticket triage process
On Thu, Sep 17, 2009 at 1:38 PM, Ben Davis wrote: > So by documentation, do you mean updating the official django docs, or > better documentation in the code itself? Yes :) As a general rule: * Self-documenting code is fine sans comments, but anything non-obvious needs explanation in the code. * All public APIs must be documented in the official docs. No exceptions. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: decorator_from_middleware change
On Mon, Sep 21, 2009 at 1:21 PM, Luke Plant wrote: > However, decorator_from_middleware is a pain, since it doesn't always return a > an actual decorator, for "historical reasons". I need to change this to fix > the bug. Is anyone against this? No, I think this is precisely correct. I've been meaning to do exactly what you're proposing for a while myself; just haven't gotten around to it. > decorator_from_middleware isn't actually documented anywhere I actually avoided documenting it because it's broken. Once you fix it, we should (i.e. I will, if you don't have time) document it. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: CSRF proposal and patch ready for review
On Tue, Sep 22, 2009 at 7:12 AM, Russell Keith-Magee wrote: > At this point, I'm convinced, mod the minor things I've flagged. > However, I'd like to see Jacob and Malcolm chime in before this is > committed. I've mostly stayed out of the discussion because I haven't had much helpful to say that isn't being better expressed by someone else. But for the record I am following this closely, and it seems to me that y'all are narrowing in on a pretty good solution. That is, making CSRF protection built-in seems to be the best approach. I did a quick survey of other web frameworks' CSRF protection, and found: * CSRF protection is an optional component (something like SafeForm) in Pylons and TurboGears, and nobody seems to use it (judging by the lack of documentation, lack of examples, and lack of questions about it on mailing lists) * CSRF protection is optional (again, something like SafeForm) in Symfony and CakePHP, and nobody seems to use it (similar criteria). * CSRF protection is a built-in-but-optional bit in Zend (you can add a "csrf field" any form to get automatic CSRF protection), and it seems to be used regularly. * Rack::CSRF provides middleware-level CSRF protection to Rack apps, and seems to be used with microframeworks (e.g. Sinatra) regularly. * Ruby on Rails provides built-in, completely transparent CSRF protection, and nearly everyone uses it. Based on this quick-and-dirty evaluation, it seems the unifying factor is that nobody really uses CSRF protection unless (a) it's built in or (b) it's too late. Or, put another way, how many people got template auto-escaping right before we made it automatic? I'm gonna give Luke's latest a try tonight if I can, but it looks pretty good. Jacob PS: I'm with Simon that we need a better shortcut for render-with-request-context. I'm gonna have to think a bit more about what that should be, though. --~--~-~--~~~---~--~~ 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: decorator_from_middleware change
On Tue, Sep 22, 2009 at 4:16 PM, Luke Plant wrote: > James B - do we have a place to list things like this i.e. things > that probably should go in release notes? I think it'd probably be best to just start docs/releases/1.2-alpha.txt right now. We can list this stuff as we add it, and then someone (probably James or I) can clean it up into a solid doc in time for the release. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django 1.2 roadmap and schedule
Hi folks -- Yup, it's that time again! For the tl;dr-ers, here's the short version: * We're aiming to release Django 1.2 on March 9th, 2010. * We'll begin voting on features for 1.2 very soon (today or tomorrow). * We're modifying the process slightly from last time; in particular, we're going to be *much* more hard-nosed about dropping features to meet deadlines. Practically, this means no more "must-haves" this time 'round. Full details, and a full schedule, are at http://code.djangoproject.com/wiki/Version1.2Roadmap (thanks to Russ; he wrote most of that). I do want to take a moment to highlight what we're doing different this time around. As y'all probably noticed, we missed the 1.1 release date rather badly (i.e. by nearly 3 months). That's not a good thing; if we're going to be doing date-based releases, we need to actually hit the dates we specify. The main problem, it seems, was that we simply put too much weight into the idea of "must-have" features. Those are really hard to pull off in all-volunteer communities such as ours; you never know when a contributor will change jobs, or go through an acquisition, or have a baby, or just simply lose interest and wander off. Really, the only way to deal with this pragmatically is to drop the idea of "must-have" features. If you think a feature should be in v1.2, you need to commit to working on it. That's it. We're still gathering feature requests for 1.2 (see http://code.djangoproject.com/wiki/Version1.2Features), but we're going to work voting differently. Instead of categorizing features into "must-have / should-have / pony" categories, we're going to simply mark them high/medium/low priority, meaning: * High Priority: A core developer is actively engaged in the ticket. * Medium Priority: A core developer is interested in the ticket, but requires someone to do the work. * Low priority: No core developer has declared a specific interest, but if a good implementation appears, that may change. The voting process plus the use of "High Priority" rather than "Must have" aims to reflect the reality of Django development. Any finished code will be committed, regardless of schedule. If a feature still needs some design work, that's fine - as long as the work is done by the feature freeze. Again, for all the full details read http://code.djangoproject.com/wiki/Version1.2Roadmap. I'll be watching email and on IRC all day to answer questions, and I'll have a form for voting on 1.2 features up shortly; watch this space. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Tutorial Refresh
Hi Rob -- First, thanks for taking this on. The tutorial indeed needs some good lovin'; glad to see someone stepping up to the plate. I don't have a huge amount of bandwidth these days, but I can commit to writing a bit, and to editing anything you or anyone else writes. On Fri, Oct 9, 2009 at 9:41 AM, Rob Hudson wrote: > * How do people feel about a tutorial that covers a complete site? Like you, I think it's the best way to teach Django. A complete site can show off more parts than just a small example project can. > * How do people feel about that site being Django snippets? Mmmm... that I'm not so sure about. Partly because this steps on already trodden ground -- James' book (Practical Django Projects) goes through djangosnippets as part of the book -- but also because it's a somewhat insular example. That is, pastebins (of which djangosnippets is a particular complex instance of) are the type of tool that really only highly geeky folks use. Django's got a wider audience -- I know Django users who are primarily journalists, designers, biologists, ... -- and ideally the example we use should have relevance to a broad cross-section of Django's audience. Of course, all that said, I don't have a better suggestion other than the tired personal blog example. So once again this is "if you build the bikeshed you get to paint it" territory. > * Comments on the proposed outline? Are there any important steps > missing? Ordered logically? Feel free to add detail to any step. Couple of things: * This new tutorial absolutely should cover pip+virtualenv, most likely right off the bat. * We should de-emphasize the "apps live inside of projects" thing. virtualenv gets the same effect we were shooting for there with much less mess. * Testing ought to be covered from the start -- I'd like to see every little bit cover how to test it. > * Do we cover things not in Django -- like model migrations, search, > RESTful APIs -- using 3rd party Django apps? I think the best idea would be cover how to find, install, and use third-party apps, and then link to some popular ones. But leave the actual how-tos to those authors. > * Would it be possible to do this openly, with easy user comments, > like the Django book? Is that software available? Heh. Sorta. The JS is okay and if you view source you should be able to figure out how to find it; the backend code is a terrible one-off, though. However, I'm not totally sure that comments make a whole lot of sense for documentation. We had comments on the docs for a while, back in the day, and they just confused people. The comments were mostly the type of questions people *should* be asking on django-users or in IRC. Since nobody who could help them was reading the comments, they didn't help at all. The other major open source projects with comments (PHP, PostgreSQL) also seem to show similar trends. PHP's doc comments, in particular, are a morass of bad advice. The ideal, I think, would be a contextual *editing* tool: something like the comment system, but allowing people to suggest changes that editors could easily apply. That way people could fix typos, suggest better wording, etc., but also not confuse the situation with bad comments. > Also, if we're going to pull this off we're going to need people to > help in a variety of ways. So I'm also curious who might be > interested. We'll need: authors to write some sections, reviewers to > give feedback, editors to clean up text and bring uniformity to the > whole thing, developers to make sure the software the tutorial is > describing is coded using best practices and works, a handful of > people to drive the process and foster community involvement, etc. Well, in grand Django tradition, by suggesting this, you've volunteered to be in charge :) But sign me up as an editor (language and code), at least, and I'll try to help out by writing some sections, too. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal for 1.2: built-in logging with django.core.log
On Fri, Oct 9, 2009 at 4:33 AM, Simon Willison wrote: > For anyone interested in following this, I've just started a > (currently experimental) branch on GitHub: > > http://github.com/simonw/django/tree/logging One big question I have is about performance: have you done any a/b testing against trunk to see how much adding logging -- especially upon every SQL query -- impacts performance? For me, at least, performance is going to be the critical factor. It's clear that even a do-nothing logger will add some overhead. If we're talking fractions of percents here, fine... but if there's a measurable performance hit that's going to be a big problem, and it's probably best to be tracking speed as we go along here. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django 1.2 feature voting
Hey folks -- Like last time 'round, if you'd like to express an opinion about features for Django 1.2, go and vote: http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en I've reorganized the 1.2 feature list (http://code.djangoproject.com/wiki/Version1.2Features) into a spreadsheet, and added short codes so we can have a shortcut when we talk about things. I've put my votes, and comments, into that sheet, and I'd like to invite you to share yours. I'd like to ask committers and anyone else to send me their own rankings. The easiest way is just to copy the spreadsheet and send it to me when you're done, but if you're anti-google just email me something I can read with codes, scores, and any notes. I'll add other folks' rankings to the master page as I get 'em. Committers: please get me your thoughts ASAP. I'd like to have a draft feature list for 1.2 out by October 20th. Please use the standard +1/+0/-0/-1 ranking. In this case the scores have some additional meaning: +1 -- "Yes!" For "must-have" features. A +1 from a committer means that s/he will champion the feature, guide the implementor (or implement it personally), review the patch, and commit the feature personally. A +1 from a non-committer is an offer to personally work on the feature, or to help the person working on it by reviewing the patch, testing, etc. +0 -- "OK" For features that are a "good idea". A +0 from a committer means that s/he will not stand in the way of the feature, but also won't personally invest much effort in it. -0 -- "Meh" For features that don't seem all that hot. A -0 from a committer indicates disapproval, but that s/he won't argue against the feature if another committer approves it. -1 -- "No!" A strong vote against. A -1 from a committer essentially is a veto. No features will be checked in with a -1 vote from a committer; only if s/he gets talked up to a -0 or better will the feature happen. Using these votes, we'll make lists of "high", "medium", and "low" priority, and "rejected" features. These lists will be based on the following criteria, but remember there's a holistic aspect to this process. We'll use the votes to draft a feature list, but we'll also open up the list for discussion and make changes accordingly. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 2:27 AM, Russell Keith-Magee wrote: > Lastly, one issue that seems unaddressed is the transition plan for > replacing user.message_set. The preamble to the wiki page makes a > compelling argument for ditching message_set, but remains silent on a > proposal for how Django (as a project) should be treating this new > alternative. This is my main concern, and the thing keeping me from being enthusiastic about the current state of the proposal. Many apps -- including, notably, django.contrib.admin -- rely on user.message_set. We can't simply remove it; we need to follow a deprecation schedule. But we also shouldn't just keep two parallel "messaging" implementations; that's silly. The best solution, I think, would be to implement user messages (user.message_set, get_and_delete_messages, etc) in terms of the new framework, and then gradually deprecate and remove the old APIs. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 11:13 PM, Paul McLanahan wrote: > I took what Jacob said to be the opposite. It sounded to me like he > was suggesting that we keep the existing user messaging api, but > change the internals of it to use the new notifications framework for > storage. In my head it goes something like: Right, that's exactly what I meant; thanks. I'm trying to avoid having two incompatible messaging systems in Django. I agree that linking messages to sessions makes more sense than linking them to users [1], but we can't just remove the user messages API outright. I'd like a good transition strategy, so it seems the best way would be to keep the user messages API, but switch it to use session messages under the hood. Or am I missing something? Jacob [1] Just as a historical note: the message API was never really intended for public consumption; it was added as a lightweight way of giving success messages in the admin. It was originally really just a hardwired in part of the admin, and as such I'm not surprised it doesn't work for a lot of other uses. --~--~-~--~~~---~--~~ 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: lazy auth context processor
On Wed, Oct 14, 2009 at 7:24 AM, Luke Plant wrote: > I want to fix #6552 (also #12031), and I've attached a patch that > makes the auth context processor lazy. The patch looks good to me. The approach is a bit hard to follow what with the multiple types of lazyness involved, but it makes enough sense to me. I'm fine with this going in. Is ``ContextLazyObject`` intended on being a public API or an implementation detail of the auth context processor? If it's the former, it should probably be documented; if the later I'd suggest just moving it into the auth context processor and being done with it there. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: lazy auth context processor
On Wed, Oct 14, 2009 at 7:30 AM, Alex Gaynor wrote:
> I think changing the result of {{ user }} in the template is a bad
> idea.
Eh, I don't think it's a big deal. I just grepped through a *lot* of
Django code and can't find that use anywhere.
> Luckily it can easily be solved by adding an __unicode__ method
> that proxies the request to the wrapped object.
True, also, and probably worth doing. But like I said, no big deal either way.
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: shortcut proposal
On Fri, Oct 16, 2009 at 7:39 AM, Russell Keith-Magee wrote: > 4) Add a completely new shortcut: > > bikeshed(request, *args, **kwargs) > > which does exactly what render_to_response does, but instantiates a > RequestContext. I've deliberately chosen a nonsense name - at the > moment, deciding if this is the solution we want is more important > than the actual name. > > Personally, I'd actually be in favour of (4). This is such a common > use case - If we're going to do this, it makes sense that the shortcut > really is short. Me too. I'd like this shortcut to be (similar to?) Simon's TemplateResponse (http://code.google.com/p/django-openid/source/browse/trunk/django_openid/response.py). I'm going to have to introduce something very much like this to get class-based generic views done, so it makes sense to kill two birds with one stone. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for a solid django/python developer...
Hi Sanford -- This is the wrong place for a posting like this -- django-developers is for discussion of core Django development. You'll be better off posting this to django-users and/or djangogigs.com. Good luck! Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
Hi Yuri, Mart -- I feel that I need to make it clear that I'm not ignoring you, or this conversation. However, the tone is so hostile and unprofessional that it'd be a waste of my time to try to engage, so I'm simply going to stay out. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
On Tue, Oct 20, 2009 at 10:52 AM, mrts wrote: > Jacob, I'm afraid you totally misunderstood me. > My message was intended to encourage people to > scratch their own itches more now that it's so > much easier -- and, of course, give back -- > instead of grumbling on the mailing list. Yup, that's very constructive advice, and my apologies: I was mostly referring to Yuri's message when I talked about tone. Although you're both talking about forks, you're doing it in a much more constructive way. You have to understand that historically the fork as been the nuclear option in open source. Threatening to fork the code is roughly the equivalent of saying "screw you guys." Forks diverge quickly, and reconciliation becomes difficult, and so it's hard to feel any desire to engage. I understand you're saying something different here -- DVCSes have, to a limited degree, changed the story when it comes to forks. Rather, it's enabled a middle ground -- distributed branches -- that allow many of the benefits of a fork without all the heartache. What's frustrating, though, is hearing that you have a problem with our workflow without any concrete suggestions to improve it or offers of assistance. There's a general theme underlying most of this "angst" (as you call it): the tone implies that you're somehow entitled to our (core developers) time and energy, when we're just as stressed, harried, and busy as you. We're *volunteers*. We work on Django because we *want* to, because it scratches our own itches. This sense of entitlement to our time and energy is rude and offensive. If *anything* gets done, it's because someone volunteers to do it. If things aren't getting done, volunteer. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The this-needs-to-be-in-django angst
On Tue, Oct 20, 2009 at 9:35 AM, Yuri Baburov wrote: > how would you reformulate this in friendly and professional tone so > this can be discussed? I don't have time to teach you how to communicate professionally. Reading your message first makes me feel angry, then dismayed. It makes me feel as if all the hard work I've put into Django doesn't matter. It makes me think there's really no point in doing any further work, because someone will just come along and crap all over it again. You need to empathize with how someone's going to feel reading your message. Until you do, people are going to ignore you at best, and get into a flame war at worst. This is your problem, not mine. But since good communication is a two-way street, I'll give you a hand. Why don't you try making some concrete, actionable suggestions about how you'd like to volunteer to improve things? If you see something broken, how about starting by offering to fix it? Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help me write tests for my patch on template rendering
On Wed, Oct 21, 2009 at 9:29 AM, Peter Bengtsson wrote: > But how do I run these? It takes many many seconds to run the whole > suite. See http://ericholscher.com/blog/2009/oct/16/easy-running-django-test-suite/ if you need help running the test suite. Remember: `runtests.py` uses the same mechanism as Django's `manage.py test` does. So just like in application tests, you can limit your tests to just a single app using `runtests.py `, so in your case `runtests.py templates` will run just the template tests. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Feature lists for 1.2
Hi folks -- Based on the votes and comments I've received for Django 1.2 I've prepared a breakdown of features into high, medium, and low priority: http://code.djangoproject.com/wiki/Version1.2Features. I've noted associated committers and, where I know 'em, lieutenants. Please make corrections if needed. If you need clarification as to why a particular feature is classified where it is, or if you want to see our comments, please check out the master vote spreadsheet: http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpNkdLd3hqZzdYR3c&hl=en. I'm happy to clarify anything that's not clear, but please lets not have an argument about "low" vs "medium" or whathaveyou. Remember: these are only guidlines. Anything complete by the feature freeze deadline (December 22nd) is a candidate for inclusion. So: we've got sixty days to get new features in - let's go! Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature lists for 1.2
2009/10/23 kmike : > Some features from wiki proposal page don't get their way to google > spreadsheet (ex: 2 cache-related proposals) and they are not mentioned > in the final features page neither in a list of accepted features nor > in a list of rejected features. That's because they were proposed too late and/or were not clearly specified. > I understand that there are some valid > reasons for that but, out of curiosity, what are their 'official' > status? Same as everything else: get the code done by December 22nd and it goes in. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature lists for 1.2
> So any tickets that have the full gambit of patch/docs/tests should make it > into 1.2? In theory. Keep in mind, though, that us committers have limited mental bandwidth so we can't absolutely promise to get to every single ticket. I'll do my best, of course, but at the end of the day I'm going to prioritize the features that the aggregate voice of the community seems to want most. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.2 feature voting
On Mon, Oct 26, 2009 at 7:42 AM, James Bennett wrote: > On Mon, Oct 26, 2009 at 6:53 AM, kugutsumen wrote: >> Support for non-relational databases (AppEngine, #10192) +1 > > Repeating once again: the voting's over and done with. The proposals > have been assigned their priorities. Time to move on. ... to doing work. If you're serious about seeing a feature in 1.2, then the best way to get it done is to step up and help out. Waldemar Kornewald seems to be doing a great job coordinating work around non-relational backends, so I'd suggest reading through the thread he started last week and figuring out how you can pitch in and help out. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Buildbot failure
On Mon, Oct 26, 2009 at 9:49 PM, Karen Tracey wrote: > I don't know who maintains or has access to the buildbot machine, It's me, probably. Buildbot's in bad shape, currently; it's basically another part-time job just keeping the damn thing running. I've more or less given up and am working on pony-build instead. Watch this space. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: __in and comma-separated strings.
On Tue, Oct 27, 2009 at 10:57 AM, Jerome Leclanche wrote: > I've got a patch to let __in accept comma-separated strings; I'm using > this locally to avoid going through the trouble of splitting a string > before processing a GET. I'm -1 on this. Is `filter(foo__in=s.split())` really all that hard? Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: __in and comma-separated strings.
On Tue, Oct 27, 2009 at 11:36 AM, Jerome Leclanche wrote:
> Point still stands, it's impossible to pass a true iterable (1-char
> iterables don't count) to a GET.
What?
>>> from django.http import QueryDict
>>> q = QueryDict('a=1&a=2&a=3&b=4&b=5')
>>> q.getlist('a')
[u'1', u'2', u'3']
>>> q.getlist('b')
[u'4', u'5']
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: CSRF changes - backwards incompatible
On Tue, Oct 27, 2009 at 1:54 PM, Luke Plant wrote: > There is a patch on http://code.djangoproject.com/ticket/12095 that > tries to address this. Repeating what I said on #django-dev this morning, I'm +1 on this patch. Rending forms via an inclusion tag is a pretty common pattern [1], and we shouldn't break it. I'm just fine special-casing the CSRF token in inclusion_tag. Jacob [1] At least a couple of Django training programs, including the ones I do, teach this technique. It's also in at least one book. --~--~-~--~~~---~--~~ 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: QuerySet.exists() and __nonzero__
On Mon, Nov 2, 2009 at 4:35 AM, Jiri Barton wrote: > I was wondering if a consensus has been reached and __nonzero__ > could use the new QuerySet.exists()? This was discussed, and Luke explains why __nonzero__ can't do this optimization here: http://code.djangoproject.com/ticket/11402#comment:5. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Call for feedback: First GSoC patch ready to land
Hi Russ -- I'm +1 on merging the patch immediately. I have some feedback on the couple of issues you raised below, but I see no reason they can't be addressed after merging. On Fri, Oct 30, 2009 at 3:33 AM, Russell Keith-Magee wrote: > The automatically generated m2m model is the equivalent of the following: > > class Book_authors: > book = ForeignKey(Book) > author = ForeignKey(Author) I can't quite see how you'd "get at" this model class, should I want it. I guess I could go through `django.db.models.loading.get_model`, right? Is the intention to make this class an internal implementation detail? If so, then it's just fine that it's not directly available... but if this model is supposed to be available to public code then do we need a better way to expose it? I ask because... > * #11795 (allowing admin inlines for m2m objects) becomes a 2 line > fix, plus documentation. Since this patch makes m2m tables fully > fledged Django objects, you can reference them in the models= line of > a TabularInline. m2m inlines are actually possible without any change > on top of this patch - but with two extra lines, it becomes a lot > easier to use. ... it seems that to make this fix you'd need to somehow "get at" those related models. Right? > * #5537 becomes a purely documentation fix. If you use a related_name > of '+' on your model, the related object is hidden. The only question > here is whether we want to document this change - so far the '+' thing > has been an internal implementation issue, so we need to decide if we > want to make this official. `related_name="+"` makes me wince. It's entirely unclear (to me) that "+" means "hide the reverse relation", so I'm -1 on documenting that fact. However, it's useful behavior, so why not just add a constant to `django.db.models` for that? It'd then look like:: fk = models.ForeignKey(ToModel, related_name=models.HIDE_RELATED) Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Last chance to object to new features
On Mon, Nov 2, 2009 at 10:02 AM, Russell Keith-Magee wrote: > A quick reminder - if you have any objections or feedback on #10109, > the M2M refactor [1], I intend to land this patch in approximately 48 > hours. I've left a few comments in that thread, but they don't need to be addressed pre-merge. Fire away! > Also, following some mailing list and IRC discussion [2], I'll be > trying to land #10355 at the same time. This is the addition of the > email backend API. I've left a few notes on the ticket. The only one that needs to be addressed pre-merge is a simple design decision, and the final call's yours. Thanks! Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Transactions
On Mon, Nov 2, 2009 at 11:27 AM, Ben Ford wrote: > I'm really curious though -- can anyone remember far back enough to > know where this came from? I haven't been able to find a single > mention of DISABLE_TRANSACTION_MANAGEMENT anywhere in django's > history! I'm pretty sure this is a documentation issue -- I think `DISABLE_TRANSACTION_MANAGEMENT = True` in the docs should just be `TRANSACTIONS_MANAGED = False`. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: https for code.djangoproject.com/svn
On Mon, Nov 2, 2009 at 12:23 PM, Alexander Konovalenko wrote: > Personally I can live without full SSL support because there are > work-arounds, but svn checkout over SSL is essential for me. It's on my todo list. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Calling update() on EmptyQuerySet updates all rows in database
On Tue, Nov 3, 2009 at 7:42 AM, Jens Ådne Rydland wrote: > This seems to be caused by EmptyQuerySet not overriding update(), > shouldn't this just return 0? Yup, that's a bug. Can you please open a ticket so that we don't forget this? Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Nov 3, 2009 at 12:27 PM, Waylan Limberg wrote: > I couldn't help but notice the docs suggest setting MESSAGE_STORAGE like so: > > MESSAGE_STORAGE = 'cookie.CookieStorage' > > Just yesterday, in reference to another upcoming feature, Jacob > commented that he would prefer all such settings to require full paths > only. In other words you would remove the attempt to import from a > default location first. So the correct setting would be: > > MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie.CookieStorage' > > Obviously, it's not my place to say for sure, but I got the impression > this should apply to all new features. Yes, please. Special-casing built-in backends requires more code and leads to the impression that external backends are somehow second-class citizens This isn't -- or shouldn't be -- true. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Regularly-scheduled Django sprints, first December 11 - 13
On Wed, Nov 11, 2009 at 3:57 PM, mrts wrote: > Done, http://github.com/django-mq/django-mq . > > I'm willing to regularly review pull requests and add > collaborators who are willing to do the same. I'll keep an eye on your queue; I can easily push good patches from there upstream to SVN. If you stick patches into separate branches -- I suggest naming 'em something like "trac/1234-short-ticket-desc" (where 1234 is the ticket number) -- that'll make it easy for us Githeads to merge in ticket fixes you post there. Please, though, stress to people who want to use your queue that they should *also* post patches to Trac. It's easier to review that way, and it's more friendly to those not using Git. Thanks Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: actions & triggers
Hi Creeper -- On Thu, Nov 12, 2009 at 11:14 PM, creeper wrote: > I'm new to Django . As well versed with Drupal i would like to know > actions & triggers type feature in Dj. May be some of you familiar > with such type concept in Dj ? This question ought to be directed towards django-users; that's where all the dicussion of *using* Django occurs, and you're likely to find other people there who know Drupal. This list, django-developers, is for discussion of developing Django itself, not user questions. Good luck! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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=.
Re: Conventions around plugable backends
On Mon, Dec 7, 2009 at 11:05 AM, Adrian Holovaty wrote: > Unless Jacob feels strongly otherwise, let's go with class-based. Nope, I don't feel strongly at all. I think I agree that I've a slight preference for the explicitness of naming the class "out loud," so let's do that. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
Django 1.2 progress assessment
Hi folks -- According to our timeline, we're at (a bit past, actually) the point where we need to take a quick look at progress towards 1.2 and decide whether the current timeline still makes sense. Right now, we've completed 4.5 features on the 1.2 priority list: * Comment admin actions (Contrib-10). * Improved CSRF protection (Core-01). * The first half(ish) of merging multidb (GSoC-05) * QuerySet.exists() (ORM-10) * Email backends (Email-01) Additionally, a few features are in or close to last-call stage (multidb and the smarter if tag). Our current roadmap calls for large feature freeze on December 22nd, and a complete freeze on January 26th. So the question is: given what we've got done, and guess at what we will get done, is the current timeline still feasible, or should we push the timeline? My opinion is that we should keep the schedule as-is. The features we've got done so far aren't all huge and game-changing, but if we released 1.2 with the features *as they stand right now*, it'd still make a solid upgrade. If we can indeed get multidb merged, that'll be a killer feature, but if it's not done I don't want to wait for it. Not ever release of Django needs to be a home run; I'd settle for a base hit every time. Thoughts? Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Sprint issue tracking / triaging
On Mon, Dec 7, 2009 at 3:46 PM, Jeremy Dunck wrote: > Obviously, I can do triaging and provide feedback on patches. Can > I be blessed to say "Ready for checkin"? Please - that'd really help me. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Django 1.2 progress assessment
On Mon, Dec 7, 2009 at 4:13 PM, Jeremy Dunck wrote: > Perhaps I missed the gripping conclusion, but wasn't there some > outstanding work to be done on multi-db's interaction with admin? The conclusion was that we could (and should, eventually) make it easier (perhaps a `using` option on ModelAdmin, or support for picking DBs from the UI), but that for now (and probably for 1.2) we simply document using `ModelAdmin.queryset` to select a DB with `using`. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth
Hi Russ -- This is looking pretty great; I'm a big fan of this approach. I've looked through the places I've needed to work around this problem with serializers, and your fix would work in every case, so I think you nailed it. I do, however, have one wrench to throw into the works: As it stands, this gets incredibly close to what we'd need to support composite primary keys! The primary thing standing in the way of getting composite PKs is an API to refer to objects by something other than a single value; your `surrogate_key`/`get_by_surrogate` is that API. Now, I'm not suggesting that we shave the CPK yak just to get serialization of content types. However, it might be worth a bit of bikeshedding in the API to future-proof it so that 1.3 could grow CPK support out of this work. All that to say: perhaps it'd be worth naming it something other than "surrogate"? On Fri, Dec 4, 2009 at 11:39 AM, Russell Keith-Magee wrote: > Documentation is still to come. For shame! :) :) Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Django 1.2 progress assessment
Okay, I've not heard any voices requesting that we push the release. So we're still on the same schedule. Let's do it! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: #7052 - Fixing serialization for contrib.contenttypes and contrib.auth
On Tue, Dec 8, 2009 at 5:15 PM, Russell Keith-Magee wrote: > There's overlap, but it isn't necessarily a perfect match. Good points -- you've clearly thought this through farther than me. Consider the wrench withdrawn :) If you need another set of eyes on the code, I'm happy to give it a review later this week and/or during the sprint this weekend. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Ticket #12171
On Sat, Dec 12, 2009 at 5:34 PM, ab wrote: > or because the Django project thinks it's supporting a backend that > actually no one is paying attention to. Probably this. psycopg 1 hasn't been updated since October 2005; I can't recall anyone I know who's still using it. That said, we claim to support it, so we'll fix it. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
Deprecating psycopg 1
Hi folks -- I'd like to start the process of deprecating and removing support for psycopg 1. Why? * psycopg 2 is better in every way. * psycopg 1 hasn't been updated since October 2005; it's basically a dead end. * I don't know anyone using it in production. * For the couple-three people who *are*, it's now possible (and reasonably easy) to maintain an external backend. I'm proposing the following very predictable timeline: Django 1.2 Use of the "postgresql" backend raises a PendingDeprecationWarning. Django 1.3 Use of the "postgresql" backend raises a DeprecationWarning. Django 1.4 Remove the "postgresql" backend from Django (and put it on bitbucket/github?) Any objections? [I'm deliberately not discussing anything regarding the renaming of the "postgresql_psycopg2" backend. I have a bigger proposal I'd like to make around that, but that's gonna have to wait for 1.3.] Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Deprecating psycopg 1
On Sat, Dec 12, 2009 at 6:36 PM, Jerome Leclanche wrote: > I'm guessing it's the standard way to do things and this may be a bit > offtopic but still, out of curiousity, since the PendingDepWarning is > not visible by default doesn't this actually give the users just the > illusion of more time to fix their code? That's the pessamistic version, yes. I prefer to think of it like this: Django 1.2 ships. Users read the release notes, and notice that psycopg1 is now deprecated and will be removed. It's still there, and still supported, so they can upgrade quickly and not have to be stuck on 1.1. Django 1.3 ships. Now, using psycopg1 spews ugly error messages to the console and Apache's error logs. But psycopg1 still works, so users can upgrade immediately and get around to fixing the ugly warning messages at their leisure. Django 1.4 ships. Those who've ignored both the release notes and the error messages over the last year (or more) get what they deserve. The main point is this: upgrading from Django 1.N to Django 1.N++ should be a no-brainer. We want our users to upgrade as quickly as possible: this makes our jobs as maintainers *much* easier. To encourage upgrades, we make them easy. This means long deprecation schedules, and it means gradually working up to things. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Call for final review: #7052 (natural keys in fixtures) and #6262 (cached templates)
Hey Russ -- I've reviewed both these patches and they look great. I'll probably proof the docs at some point, but that shouldn't prevent merge -- merge away! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
Last call: #11863 (Model.objects.raw)
Hey folks -- Forgot to mention it during the sprint this weekend, but I've pushed a RC patch to #11863, Model.objects.raw(). If anyone's got any feedback, let it fly. Otherwise, I'll be checking this in in a couple-three days or so. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Last call: #11863 (Model.objects.raw)
Thanks for the review, Jeremy. On Tue, Dec 15, 2009 at 5:31 PM, Jeremy Dunck wrote: > This bit doesn't seem to be true; It seems that missing fields will > raise InsuficientFields instead. Am I reading it wrong? Ah, good catch. I'd intended to remove this behavior as it's overly strict -- the whole point of ``raw()`` is that it lets you play fast and loose with best practices. The code now matches the docs. > RawQuery._populate_cache does fetchall(). This is sort of surprising, > since normal QuerySets go out of their way to avoid fetchall. > RawQuerySets are not as lazy as normal querysets in that normal > querysets do fetchmany. If this was intended, it might be worth > pointing out. In fact, I think RawQuerySet.iterator won't do what > people expect. Yeah, this is annoying: SQLite doesn't support cursor.rowcount until all the rows have been fetched, so supporting a cheap __len__ is hard. After thinking about it for a while I've decided just to ditch __len__ and return the raw cursor for __iter__. That's closer to the "raw" database access anyway. Users can always ``len(list(q))`` if they must. Nothing in the docs mentioned len() any way, and I can't see it being all that useful -- as long as you're writing raw SQL, COUNT(*) is going to be more efficient anyway. > On "admonition:: Model table names" - Person._meta.db_table would have > the value, and it might be better to be more explicit about it. But > it's an "_" API, so maybe we don't want to make it clearer after all. > ;-) I'm leaving it out deliberately -- we've avoided stabilizing _meta (so far), so until we do (or add an official model reflection API) I'm leaving it out of the docs. > "You'll use ``%s``" > Is that back-end independent? It looks like it gets evaluated by > whatever backend you're using, and so would depend on DB-API > paramstyle. Nope -- ``connection.cursor()`` returns a ``CursorWrapper`` that translates query styles into '%s' reguardless (see django.db.backends.sqlite3.SQLiteCursorWrapper for one example). > RawQuery.validate_sql excludes anything but selects, but Oracle uses > comments to do query hinting. *** boggles *** (Looks like it's not a problem, though.) New patch uploaded - let me know if you see anything else. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Last call: #11863 (Model.objects.raw)
On Wed, Dec 16, 2009 at 6:51 AM, Russell Keith-Magee wrote: > No need for workaround docs - I've just uploaded an RC3 patch that > implements deferred fields. Sweet! I love it when other people do my work for me... > The one gotcha on this patch is that it now requires that you request > the primary key when you retrieve an object. [...] > This is slightly more restrictive than Jacob's RC2 patch - but I think > the RC3 behaviour is preferable. I agree, and it actually opens up another use for raw() -- fetching lazy objects where you've just got the ID, say in a materialized view or whathaveyou. I'll probably make a change to the docs to emphasize that you need the primary key a bit more strongly, but I'm quite happy with this change. Thanks! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Last call: #11863 (Model.objects.raw)
On Wed, Dec 16, 2009 at 10:13 AM, Jeremy Dunck wrote:
> This won't work, because deferred fields are descriptors, and
> accessing foo.field would run the query.
>
> Something you could do is foo.deferred_fields.field_name -> Boolean,
> but that seems pretty clunky to me.
You can get at this information now if you really need to::
>>> e = Entry.objects.defer('body')[0]
>>> [f.attname for f in e._meta.fields if f.attname not in e.__dict__]
['body']
But the point is that deferred fields are an optimization. You
shouldn't need to know which fields are deferred: you should be adding
``defer`` as a last-step optimization once you *know* the fields in
question aren't needed.
IOW, why do I need to inspect the ``Entry`` to figure out what's
deferred? I just *told you* what's deferred in the previous line.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-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: Ticket #399 -- bigint support
On Wed, Dec 16, 2009 at 1:04 PM, Karen Tracey wrote: > I've uploaded what I think is a commit-ready patch for adding > BigIntegerField. Barring any major objections I'd like to commit this in > the next day or two. Looks good to me - go ahead. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Final call for feedback: Multi-db
On Sat, Dec 19, 2009 at 3:46 AM, Jani Tiainen wrote: > Haven't run any tests, but as a small request - I would be very happy that > you guys take a look ticket #11017 it's quite performance killer to some > selects on char fields (specially startswith) on Oracle. This has nothing to do with multidb; let's try to keep things on track, please. We've got about three months of bug fix time set aside soon; right now we're working on getting the last few features into 1.2. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Feedback: Syndication feed views
On Fri, Dec 18, 2009 at 2:38 PM, Ben Firshman wrote: > Patch and ticket done. Any comments? It's looking pretty perfect to me. The only things I can see missing are the various formal bits of deprecating the old and documenting the new: you need deprecation warnings, notes in the deprecation schedule document, and versionadded directives in the docs. Code-wise, though, everything looks fine. Don't worry too much about getting to all the formal stuff: I'll probably be committing this today. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Feedback: Syndication feed views
On Sat, Dec 19, 2009 at 8:33 AM, Jacob Kaplan-Moss wrote: > Code-wise, though, everything looks fine. Don't worry too much about > getting to all the formal stuff: I'll probably be committing this > today. Or not. There's a failing test in your patch:: == FAIL: test_template_feed (regressiontests.syndication.tests.SyndicationFeedTest) -- Traceback (most recent call last): File "/Users/jacob/Projects/Django/upstream/tests/regressiontests/syndication/tests.py", line 247, in test_template_feed 'link': 'http://example.com/blog/1/', File "/Users/jacob/Projects/Django/upstream/tests/regressiontests/syndication/tests.py", line 25, in assertChildNodeContent elem.getElementsByTagName(k)[0].firstChild.wholeText, v) AssertionError: u'Overridden description: My first entry' != 'Description in your templates: My first entry' -- ... and I've not yet been able to figure out what's going on. Looks like I won't have a chance to check it in before I leave for vacation tomorrow. However, I'm +1 on the way you've done this, and would very much like to see it get in. So any other committers should feel free to commit this assuming Ben can track down and fix the bug. Jacob [Failing that, I'll probably stretch the definition of "minor feature" a bit and plan to commit this for the beta instead...] -- 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: Design and code review requested for Django string signing / signed cookies
On Mon, Jan 4, 2010 at 12:34 PM, Simon Willison wrote: > We do however need to consider the places in Django that are already > using hmac / md5 / sha1 (contrib.formtools and middleware.csrf for > example). Even if we don't add the signed cookies feature to 1.2, > fixing any problems with our existing use of crypto should not be > affected by the feature freeze. There's not much point in implementing > this logic in several different places, so I think we should keep > targeting the django.utils.signed module for 1.2. Agreed - I see no issues with targeted it for the beta (but using it for signed cookies probably has to slip to 1.3). It's certainly an improvement to have a single place where this sensitive code lives. >From a worst-case-scenario standpoint, it'd make a security fix much easier to only have a single place to fix it. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Design and code review requested for Django string signing / signed cookies
On Mon, Jan 4, 2010 at 5:00 PM, Alex Gaynor wrote: > So, thinking out loud here, I know the DSF has a policy of hands of in > the development of Django, but I was thinking (out loud) that perhaps > it would be sensible for the DSF to hire someone to do a security > audit of some of this stuff. I have 0 clue about the particulars of > how anything like that works, but it was just a thought that occurred > to me. The policy isn't exactly "hands off;" it's just that the DSF has no interest in driving the development of Django. But the DSF certain can (and in my opinion should) pay for services like this *if* the development team and community thinks it's necessary. That said, I think the idea's probably a non-starter. First, like Tobias (see below) I tend to highly believe in the mantra of many eyeballs, so I'd argue that an expert review in no way absolves of the need for open peer review. However, it would tend to discourage community review -- paid work almost always discourages volunteers -- and would thus be a net loss. Second, from a more pragmatic point of view, my impression is that anyone who's actually worth paying would cost well beyond what the DSF could actually afford. Don't mean to shoot you down, though, and I *really* like the precedent you're setting by bringing this up. The main reason I wanted to have a DSF in the first place was so that we could have options like this. Even if we don't use the option this time (and I think we shouldn't) it's good for the community to know that it's available. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: idea for using RequestContext by default
On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee wrote: > I haven't taken the temperature of anyone else in the core, but you > can take it as read that Simon and myself are both +1. The sprint this > weekend would be a great opportunity to advocate for inclusion of > this. With a few tests and documentation, Simon's patch could easily > be made trunk-ready. I'm also +1 on something like ``TemplateResponse``, and especially ``django.shortcuts.render(request, template, context)``. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: idea for using RequestContext by default
On Tue, Jan 5, 2010 at 9:38 AM, Russell Keith-Magee wrote: > To clarify your position Jacob - are you advocating that > shortcuts.render() should return a TemplateReponse? Or are you > suggesting that we add a TemplateResponse *and* a shortcut.render() > that is an analog of render_to_response, but with a RequestContext? I don't particularly care how ``render`` works internally -- I'm not totally sold on ``TemplateResponse``, but I'm also not against it really. I'm just really sick of ``context_instance=RequestContext(request)``. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Question about scope of variables in template blocks
Hi Alex -- On Fri, Jan 15, 2010 at 8:41 PM, Alex Rades wrote: > I'm sorry for asking this here, but the question was raised several > time on the -users mailing list and I don't think we users have a > solution for it. I hate to be a jerk, but django-dev isn't "second-level support" or somesuch. Not getting a satisfactory answer on django-users doesn't somehow qualify the question for "promotion" here. There are a lot of other options besides django-users -- the #django IRC channel, StackOverflow, comp.lang.python, Please, help us keep this list focused, and use them. Of course, If you've got a proposal or a patch that you think would improve things then *by all means* bring it up here. Jacob PS: To speak to your original question: caching. Learn to love it. -- 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: Call for comment: #12624 Class based test runners
On Sat, Jan 16, 2010 at 8:26 AM, Russell Keith-Magee wrote: > Specifically, I want to make this change because I've had a couple of > conversations in the recent past that have gone something like: > > Them: How do you make Django do X before/during/after a test run? > Me: You write a custom test runner > Them: How do I do that? > Me: You copy this 50 line method and modify the 1 line that offends you. > Them: 1985 called - they want their code back. Heh. I've had this exact conversation a few times myself. IOW, +1 - this is a good idea. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
What The Enterprise wants from Django
Hi folks -- I had a conversation this morning with one of my clients. In the interests of being a good corporate citizen I'll refrain from mentioning who other than (a) they're big (Fortune 1000), (b) you've heard of them, and (c) they're using Django. Before our chat, they'd invited any engineers internally to bitch about Django, and they shared some of the pain points they'd come across. I took some notes; the really good news is that it's a short list, and we already know about most of it. Before I share the list, I should mention that I'm not arguing we have to immediately devote resources to these problems, nor even that we have to solve them. I'm sharing this just as food for thought, and as a perspective from a class of developers who mostly don't participate in our process at all. So: The main issue they have is multiple database support. Music to my ears (and especially Alex's :) since it looks like 1.2 will solve most (all?) of their issues. My main takeaway from this point was that the best way to please companies like this one will be to ship 1.2 on time. Which will happen. So we rock. The next big one was the "startup signal" issue -- they've got lots of code that needs to run at startup time, and there's no great mechanism to do that currently. The core devs have talked about this one a *lot* over the years, and it's obviously a hard one -- for one, there's no clear definition of what "startup" means -- but a common theme seems to be that bigger, more complex applications need some way to cleanly run one-time, expensive startup tasks. Next, we discussed the difficulty of maintaining large installations with multiple sites, a plethora of apps, and unspeakable possible combinations thereof. Django's settings mechanism is simple and easy to use, but once you have hundreds of sites it starts getting really tricky to keep things in sync across hundreds of settings files. We talked at some length about different possibilities for dynamic settings infrastructure; this would especially come in handy for folks wanting to build application servers/services like App Engine or the nascent Toppcloud. If you've not yet checked out Toppcloud, do so now. I'll wait. Finally, we ruminated over the difficulties in building rich internet applications. Sure, writing HTML/CSS/JS/Python/SQL by hand works fine, but we doesn't really have a good answer for the people who want something IDE or GUI-ish. Meanwhile, Adobe and Microsoft are putting all sorts of marketing dollars into Flex/Silverlight, and although HTML5 can do some amazing things, the lack of tooling is a big danger. (I've written at more length about this in the past: http://jacobian.org/writing/snakes-on-the-web/#s-rich-web-applications). Of course, there may not be much us backend folks can do about this problem -- I'm certainly not enough of a GUI application guy to be able to even start to think about this problem -- but the lack of an end-to-end solution will nonetheless put some off from writing web applications with open source tools. So there we are. This is very much a brain dump, and I don't really expect any concrete action to result from it. However, I found some really interesting stuff there, and I thought I'd share. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: What The Enterprise wants from Django
On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote: > I don't understand how avoiding the settings.py mechanism will produce > *more* flexibility. The problem -- at least as I see it -- is that of a intertwingulment of "application" settings with "ops" settings. As organizations get larger, roles stratify more. Thus you end up with a pretty big gulf between the ops team and the application developers. In these environments, application developers probably shouldn't be messing with things like the `DATABASE_*` settings -- in some organizations its even a breach of policy for the developers to *know* the database password! OTOH, ops types don't know what the heck to do with `INSTALLED_APPS`... And then there's middleware: some middleware (caching, etags) might need to be controlled by ops; some by apps. Obviously you can *do* this with Django, and I'd argue it's not particularly hard. Still, it's something that bigger orgs have to figure out themselves, and that can be a barrier to adoption. The enterprisey world solves this with standards like WAR and servers like Glassfish: if I'm an application developer, all I need to do to deploy is somehow produce a WAR. And if I'm a ops person, I just take that WAR and slap it into Glassfish. It's rarely that easy in practice, of course, but the execs making the tech decisions don't know that. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Feedback requested: Multi-db database routing
On Wed, Jan 20, 2010 at 10:06 AM, Russell Keith-Magee wrote: > Ok - so that's the patch. Any comments, queries, or criticisms are welcome. I'm happy -- +1. One thing, to point out, though, is that this continues the slow process of making `Model._meta` a de facto public API -- without being able to access (parts of) `_meta` this feature is basically useless. Just one more reason we need to document and stabilize _meta... Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: What The Enterprise wants from Django
On Thu, Jan 21, 2010 at 8:58 AM, Luke Plant wrote: > I would have guessed that a big issue with Django from an enterprise > perspective is its use of 'singletons'. [snip] > How much is this an issue in practice? Other than databases, it hasn't been much of an issue with most of the BigCos I've been involved with. That's because... > One solution to this problem would be to have multiple Django > instances hosting different parts of your URL space, allowing them to > have multiple settings files. Bingo. All of the larger Django installations I've worked with haven't been just one project -- they've been dozens (hundreds in one case) of little bits, often cobbled together by different teams and sometimes different companies (in-house vs. contractors vs. off-the-shelf products). Django's URL/view decoupling looks *really* nice in these cases -- Django apps, properly written, don't care *where* in the URL space they live -- so this means that Django fits in well in these heterogenous environments. And I've yet to encounter a larger company that's anything but wildly heterogeneous. Peter's question below about enterprisy complexity and the dangers of becoming J2EE are good ones; I'm glad they're part of the discussion. It's difficult to know where to draw the line between simplicity and flexibility. Right now we have exactly 90 documented settings, some of which point at classes or interfaces that themselves have more complexity. To me this already sounds way too high, but it's nothing compared to the configuration options available in other environments -- PHP has about 600 php.ini settings! -- so there's obviously a matter of taste here. It's also important to keep in mind that part of the reason Django's had (some) success in corporate environments is *because* of the simplicity, not despite it. I've heard, over and over again, that teams that have switched to Django have done so at least in part because of the simplicity and ease-of-use. So we should be careful about setting up a false dichotomy where us hippie open source freaks only value simplicity and build toys and those square suit types who love FactoryManagerFactories because CIO magazine tells them to. The real world, as always, is a lot more complex. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: What The Enterprise wants from Django
On Thu, Jan 21, 2010 at 10:24 AM, sago wrote: > Case studies are helpful if folks can share them. Just a quick note that the DSF is working on gathering case studies; getting folks who have permission to share is indeed a tricky issue. Not much is set up yet, but I, at least, would be *thrilled* to help companies using Django put together case studies that could be shared publicly. Until we've got something more formal in place, consider it a standing offer -- drop me a line if you'd like to share a success story. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: #10216 - TEMPLATE_DEBUG / TemplateSyntaxError handling doesn't play nice with Jinja2
On Sat, Feb 6, 2010 at 8:32 PM, Armin Ronacher wrote: > I would like to propose a different solution: do an instance check > against a django TemplateSyntaxError (or any other template exception > that has these .source attributes). That should be easy to accomplish > and the debug system already has a dependency on the template engine > anyways for the rendering of the UI. This sounds fine to me. Can you reopen the ticket and/or provide a patch? Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Django Design Czar
On Mon, Feb 8, 2010 at 3:42 PM, j...@jeffcroft.com wrote: > A designer ought to be able to say, "It'd be really useful to > me if the 'if' tag supported basic operators, and I'd be happy to help > someone understand the needs of designers with regard to it, but I'm > not capable of building it myself," and have that be taken seriously. Just as a point of order, this is *exactly* what happened with the smart if tag: I was against it, and then designers told me to STFU, and I did. Of course, as a general principle, Jeff's completely right that we need to be doing a better job listening to the things designers need from us. We did that very well early-on, and it helped Django become better. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: examples directory
On Mon, Feb 15, 2010 at 5:14 AM, Luke Plant wrote: > I'm prompted by #12863 [1] to suggest that we remove the whole > 'examples' directory, because: +1. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Serialization of single object instead of only querysets.
On Mon, Feb 15, 2010 at 11:43 PM, orokusaki wrote: > Thank you Karen. I've been hushed so many times about this [...] I can't find any evidence that this is the case. In fact, this appears to be your first post on django-developers. Since you're (apparently) new here, I'm happy to cut you some slack, but you need to understand that hyperbole will get you exactly nowhere around here. I appreciate that you feel strongly, but outlandish claims of being "hushed" don't help anyone. Regardless, here's how you can help: I'd like to add something about this to the FAQ. If you write an entry, I'll edit it and check it in. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Deprecating cmemcache, adding pylibmc
On Sun, Feb 21, 2010 at 8:32 PM, Jacob Burch wrote: > This is in regards to Tickets #11675 and #12427. A bit more background: I've been told at PyCon that cmemcached is unmaintained and deliberately being left to die in favor of pylibmc. Because of that I'm +1 on your proposal, and I'll argue that we not consider it a "feature addition" so it can go in for 1.2. If you can work up a patch I'll be happy to review. I have a couple of questions: > A slight rework of the memcache client that implements a base class > which resembles the current Django 1.1 memcache client. Anything that > implements the current CACHE_BACKEND setting "memcached://server:port" > would use this base class. Throw a deprecation warning if the > cmemcache library is being used in this way. I'm not quite clear how what you're talking about here. You want to raise a deprecation warning about anyone who uses "memcached://" instead of something new-style? > Additionally, add explicit subclasses for pylibmc and python- > libmemcache, so if "pylibmc://server:port", "memcached://server:port? > lib=pylibmc" or some variety there of controls what subclass gets > used. I discussed "memcached+pylibmc://", "memcached+cmemcache" etc. It's a bikeshed, though, and if you write the patch you can paint it. > Forcing the user to be explicit on what library they use could be > added later, although I don't know if it's necessary. "In the face of ambiguity, refuse the temptation to guess." We've violated this rule by guessing once; I'd like to switch to *just* use python-memcached, and force anyone who wants anything else (including cmemcached) to be explicit. We can't do that in 1.2, though, so maybe this is the warning you were talking about? i.e. warn if cmemcached is chosen automatically? > Pylibmc and python-memcache have almost identical API characteristics > (from pylibmc's docs: "pylibmc‘s interface is intentionally made as > close to python-memcached as possible, so that applications can drop- > in replace it."), and only differ in pylibmc's flexibility of memcache > behaviors and their hashing method. (See > http://sendapatch.se/projects/pylibmc/#behaviors > and http://sendapatch.se/projects/pylibmc/#differences-from-python-memcached). > The subclass should end up being fairly lightweight. Please make sure if you do this that there's a mechanism to use pylibmc's consistent hashing -- it's the main reason to switch to pylibmc. Actually, the more I think about it, if you're using pylibmc then consistent hashing should be the *default*. Thanks for getting this started! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Moving all validation into the model layer.
On Mon, Feb 22, 2010 at 11:42 AM, orokusaki wrote: > Ah, Thanks Russell. I'm new to Django Dev stuff and wasn't aware that > they don't do features for the next version and bugs for the current > beta. That makes more sense though. You'll probably want to read through our "how to contribute to Django" guide, then: http://docs.djangoproject.com/en/dev/internals/contributing/ It covers pretty much everything about how our development process works, and should help you understand how (and hopefully why) we do things around here. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: EmailBackends
On Mon, Feb 22, 2010 at 12:48 PM, Mat Clayton wrote: > Any thoughts on this as a change to the Email Backend system in django? I'm not sure why you'd need any changes to the backend system: couldn't you easily create a composite backend class that tried to send email through multiple backends? Here's my completely untested stab at the problem:: class IDontWanna(Exception): pass def composite_backends(*backends): class CompositeEmailBackend(object): def send_messages(self, messages): for backend in backends: try: backend.send_messages(messages) except IDontWanna: continue MyMultipleBackends = composite_backends(BackendOne(), BackendTwo(), BackendThree()) Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Django's testing infrastructure
On Fri, Feb 26, 2010 at 10:32 AM, Cramet Matthieu wrote: > Wouldn't it be interesting to build some Virtual Machines that people could > grab and deploy directly in the cloud ? It might interest people willing to > contribute hardware but not having much time to dedicate at maintaining it. > I personnaly have a spare Desktop with a Quad Core and 4G of RAM that could > run at leat 4 VMs. If you (or anyone else) would be willing to develop some VMs -- VMWare, VirtualBox, or EC2 images would probably be best -- I have space/bandwidth to host 'em for download. I think it's a fantastic idea. Especially EC2 instances, actually: if someone does the grunt work, I think Hudson can boot and manage them directly. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Inheritance: Create a way to subclass and override attributes of a parent class.
On Fri, Feb 26, 2010 at 5:11 PM, orokusaki wrote: > Well, I won't even try to argue with that, but there has to be a way > to conquer problems like this in Django without editing the source > code, don't you think? There are many, and we've discussed this issue at length any number of times over the years. Please take the time to read over the history here; if you've got something new to add to the discussion I'd love to hear it. Please keep in mind as a general rule that we're well aware of the problems Django has. All of us here use Django every day; for each problem you discover, I could probably recite ten. It doesn't really help, though, to make a post about each and every problem unless you can offer specific, actionable solutions. Remember that code speaks louder than words around here (and in most open source communities). It's easy to wave our hands around and guess that a solution could work; a prototype or patch is something else entirely. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Inheritance: Create a way to subclass and override attributes of a parent class.
On Fri, Feb 26, 2010 at 5:17 PM, Jacob Kaplan-Moss wrote: > There are many, and we've discussed this issue at length any number of > times over the years. Please take the time to read over the history > here; if you've got something new to add to the discussion I'd love to > hear it. FTR, here are a few of those threads. These are just the ones I could find in about 30 seconds of searching the archives; I'm sure there are more: * http://groups.google.com/group/django-developers/browse_thread/thread/1b18996852d3d1a7 * http://groups.google.com/group/django-developers/browse_thread/thread/b8a6cfc59d28b4dc * http://groups.google.com/group/django-developers/browse_thread/thread/f124083c6194dccc Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Deprecating cmemcache, adding pylibmc
On Sun, Feb 28, 2010 at 11:40 PM, Jacob Burch wrote: > Thanks all for the helpful discussion here. From the sounds of thing, > my course of action will be: > > 1) Get a patch that throws a FutureDeprecationWarning when cmemcache > is used + Change of the docs to note the coming deprecation of > cmemcache > 2) Begin working on a more involved patch that hopefully get slated in > for 1.3. Yeah, that sounds right, and thanks. Also, a step 2.5, if you'd like, would be to write a tiny app on pypi that enabled the use of pylibmc via an external cache backend. We could point to it in the deprecation notes when we explain why cmemcache is being deprecated. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Django 1.2, ManyToMany relations and legacy database support
Hi Xavier -- This is a question better asked on django-users -- django-developers is for discussion of the development of Django itself, not usage questions. As a brief answer to your question, you'll want to take a look at defining a custom intermediary model: http://docs.djangoproject.com/en/dev/topics/db/models/#extra-fields-on-many-to-many-relationships Thanks, Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: A question for the Django webmaster...
On Thu, Mar 4, 2010 at 2:45 PM, Bill Hart wrote: > I would like to get information about the Django webpages themselves. All the code that runs djangoproject.com lives here: http://code.djangoproject.com/browser/djangoproject.com > I like the visual integration that is achieved between the Django > webpages and the Django Trac page. Is there some documentation for > how this was done? I assume that this is done with Django itself? It's all done with CSS, included via a simple custom Trac template (not in the repo, but if you check the Trac docs you can see how it'd be done). So check out the CSS if you're interested. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: GSoC10 Idea: Additional queryset methods
On Fri, Mar 19, 2010 at 7:39 AM, Sh4wn wrote: > I want to refactor the QuerySet and other databases related API's, > which adds an additional method of selecting records, and provides > more control of what data you'll select, but probably is a bit more > complex than the current API. I don't want to discourage you, but... Wait. Actually, I *do* want to discourage you. The chance of this getting accepted is going to be very, very, very low. If you're going to change Django's query syntax, you're going to need to provide an incredibly convincing argument, and you're going to need to explain why this is so important, so vital, that it's worth breaking the millions of lines of Django code already out there. We take backwards compatibility incredibly seriously, so any discussion of changing the model layer needs to start there. So fair warning: you're going to be fighting an uphill battle on this one. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Validate a form's excluded fields if a value is present
On Thu, Apr 1, 2010 at 3:11 AM, Russell Keith-Magee wrote: > Melodrama aside, as we've told you before, the docs clearly say that > full_clean() isn't called by form.save(). The docs also give you the > reason - backwards compatibility. > > I don't deny that it would be *really* nice to be able to > automatically call full model validation on a model on form save - the > problem is that we can't do that while retaining backwards > compatibility. Well, *we* can't... but *users* can: just override your form's ``clean`` method, and call ``full_clean`` from there. In general, if you find yourself doing the same thing over and over in different views, it's a sign that you're operating at the wrong level of abstraction. In this case, solve the problem once by overriding what you need on the form, and then let your views be as "pretty" as you'd like. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: High Level Discussion about the Future of Django
On Sun, Apr 4, 2010 at 10:02 PM, orokusaki wrote: > This is a bit abstract, but I'd like to bring up this idea, [...] Well, I'm sorry, but I just don't have time to engage on big abstract discussions like this, so feel free to write whatever you want, but don't count on my participation. I'm also going to suggest the other core Django developers similarly ignore this discussion, though I see you've managed to get Russ to engage. I do appreciate your enthusiasm, but you seem to have forgotten a basic tenant of open source: there's one -- and only one -- way of getting your way: Write code. Show me code, and I'll pay attention to your proposals. Show me big crazy abstract "what ifs" and I, well, won't. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
Inappropriate behavior [was: Re: default delete() clear() behavior and you.]
On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton wrote: > ps. I didn't really murder a hooker in vegas This sort of "joke" is highly offensive, and isn't appropriate here. Frankly, I don't think it's appropriate *anywhere*, but I actually have some power to stop this sort of crap here, and I'm using it. Violence against women and sex workers is very real, and joking about it trivializes the very real pain of survivors. The image you posted could have been highly hurtful to those who've experienced violence; images and jokes about sexualized violence trigger painful memories. I recognize that you probably didn't intend to offend. Nevertheless, you did: I found your "joke" offensive and tasteless, and the image you posted more so. Discriminatory and exclusionary humor causes real pain and is not appropriate here. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Bug #348 and Safari.
On Tue, Apr 6, 2010 at 9:42 AM, schinckel wrote: > It seems Safari (Mac, at least) is still plagued by what seems to be > the behaviour described by http://code.djangoproject.com/ticket/348 - > when you have a ManyToMany, and have turned it into a javascript- > enabled filter box pair (SelectFilter2.js), then you get funky > behaviour. > > This is fine in Firefox/Camino, but still has duplicates (and no > pattern to them that I could find). > > Is this reason enough to reopen this ticket? A new ticket would be better -- browsers have changed a lot since Firefox 1.0.6 (wow, Django's OLD!) -- and the bug's likely to be different. You can reference #348 and mention it seems similar, but a fresh ticket without all the old history would be preferable in this case. Also, please be sure to more clearly define what's going on. You've told us that "Safari" on "Mac" has "funky behavior"; we're going to need more specific information to track it down. In particular, we need: * Your Django version. * Your ModelAdmin declaration. * What version of Safari you're running. * What version of Mac OS X you're running. * A clear definition of "funky behavior". A screenshot -- or even video -- would help loads. If you want brownie points, you'll try to reproduce the bug in related browsers (Safari on Windows? WebKit nightlies? Chrome?) Yes, I know it's a lot to do, but unfortunately tracking down JavaScript-related browser bugs is the *worst*, so we need all the help we can get! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Tiny, tiny patch - can it make it into Django 1.2?
On Tue, Apr 6, 2010 at 11:17 AM, David Reynolds wrote: > Hi, > > Just thought I'd ask whether or not > http://code.djangoproject.com/ticket/10917 would be able to make it into > Django 1.2? No. It's a feature addition, and we're well past feature freeze. Sorry, Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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.
