Re: On returning appropriate subclass instances when querying a model with subclasses

On Sun, Aug 23, 2009 at 1:54 PM, Andrea Zilio wrote: > > So seems that this idea was in fact rejected because of the O(# of > nodes in the inheritance tree) joins > needed to get all the fields from subclass tables. > You may want to loook at Alex's post on the subject:

Re: HTTP Errors

On Mon, Jul 27, 2009 at 3:47 PM, Benjamin Wohlwend wrote: > On Mon, Jul 27, 2009 at 3:27 PM, Anton Bessonov > wrote: >> >> class Http403(Exception): >>    pass >> > > It isn't quite that easy. Django special-cases Http404 (see >

Re: New in development version or versionadded

On Thu, Jan 29, 2009 at 2:24 AM, Malcolm Tredinnick < malc...@pointy-stick.com> wrote: > > Use "..versionadded::", but make the version be 1.1, not "dev". There's > a patch that we haven't applied yet, but will soon, in Trac to convert > all references to the next version to read "development

Re: one view from multiple models

On Wed, Nov 26, 2008 at 9:03 PM, xshen <[EMAIL PROTECTED]> wrote: > > is there anyone know how to create one view from multiple models? any > input is appreciated You may want to ask in http://groups.google.com/group/django-users This groups is intended for the development of Django itself, not

Re: One suggest for a new Lorem Ipsum

On Wed, Nov 26, 2008 at 10:05 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > My point is to use the text of lorem2.com for the current lorem ipsum > tag, this text is more effective for test the divs. Unless you speak Latin, it's unlikely noone will notice the

Re: One suggest for a new Lorem Ipsum

On Wed, Nov 26, 2008 at 1:29 AM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > Hi, > > In Django in somwhere is a tag Lorem Ipsum, i suggest to use Lorem Ipsum 2 > > http://lorem2.com/ I do not get the point, and by your message I'd say you've not used the lorem tag at

Re: Branches on Github

Hi, On Fri, Nov 14, 2008 at 6:37 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > Not the *best* place to post this, but it does relate to Django dev. > > Is it possible, and if so how, could one branch the Django trunk, and > throw it on Github? You should really have your own branch made up of

Re: "New in development version" equivalent in current docs?

Hi there, On Tue, Oct 7, 2008 at 1:17 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > You can't put anything with spaces in there. It feels a little > inconsistent to put 1.1 in there, since we generally hold off talking > about version numbers from the future so that bug reporters are

"things are ready" signal?

Hi there, Staring at #8638 I'm trying to find a way to hook code to be run "just after Django is completelly loaded" and found no way ;( The thing is, it's a really nice place to emit a signal if you want to do things "just after things are ready", but there's no signal for it. And, as I found

Branches "trimming" and structure

Hi ppl, In the contributing docs we can read: After a branch has been merged, it should be considered "dead"; write access to it will be disabled, and old branches will be periodically "trimmed." My English is not very good but I always understood that as "we'll remove them when they

Re: Need a programmer immediately

On Sun, Sep 28, 2008 at 6:04 PM, KnoxvilleDjangoDev <[EMAIL PROTECTED]> wrote: > > Apologies if I am not asking this question correctly You'd better post to Django-Users (http://groups.google.com/group/django-users ) this group is intended for people developing *Django* that is: The framework

Re: I want a pony: Django Cheeseshop

Hi, On Wed, Sep 10, 2008 at 4:31 PM, mrts <[EMAIL PROTECTED]> wrote: > Apps > --- > * extend them with Django-specific functionality to > o lessen magic: explicitly specify files containing models, > templates and admin bits, i.e. obsolete all forms of autodiscovery and > path

Re: I want a pony: Distributed RCS

On Thu, Sep 11, 2008 at 12:25 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 3:15 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote: > I know Gary uses Bazaar, and > I wouldn't be surprised to find that one of the other core devs uses > something really exotic like Darcs.

Re: djangoproject.com/documentation/ redirected

On Wed, Sep 10, 2008 at 11:46 AM, James Bennett <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 10, 2008 at 2:52 AM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Nice! Now the only thing left is to have 1.0 docs (aka: > > docs.djangoproject.com/en/1.0/) > > and

Re: djangoproject.com/documentation/ redirected

On Wed, Sep 10, 2008 at 6:43 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Just a quick note: I've redirected > http://www.djangoproject.com/documentation/ and everything below that > URL tree to the new docs subdomain, http://docs.djangoproject.com/. Nice! Now the only thing left is to

Re: Call for testing: new docs

Hi, On Wed, Aug 20, 2008 at 12:01 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > The docs refactor work is pretty much done; now I need a bunch more > eyes to look things over. There's still a bunch of TODOs (see below), > but it's better than the current docs and maintaining branched docs

Re: Clarification on what is getting into v1 & Ticket 3148

El mar, 08-07-2008 a las 19:34 +1000, Malcolm Tredinnick escribió: > I'll also note that that ticket has sort of weaved it's way up to "ready > for checkin" without too much participation from core developers and > it's a bit of a change. Dunno who the anonymous user was, not me ;) I didn't move

Re: Clarification on what is getting into v1 & Ticket 3148

El mar, 08-07-2008 a las 01:24 -0700, [EMAIL PROTECTED] escribió: > So our team is very fond of Ticket 3148 "Add getters and setters to > model fields" which is in the "ready for checkin" stage. Does that > mean it will be merged to the trunk soon (and thus become part of v1 > release)? Not

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

El jue, 26-06-2008 a las 06:58 +0800, Russell Keith-Magee escribió: > >> My preferred solution here would be to provide a way for test cases to > >> substitute a top level URL pattern object for the duration of the > >> test. For example: > > A patch in these lines is now attached to #7521, the

Re: Spam detection

El jue, 26-06-2008 a las 13:31 -0700, Jacob Kaplan-Moss escribió: > Help me out here: how can I make it more obvious? You missed that; > others often do to. Can you share with me some insights on how you > missed it? The sentence should be more prominent, I know nobody that will read that many

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

Hi all, You may have noticed that [7716] raised a few bugs around (#7514, #7517 and #7521) the nice one is #7521, which is now marked DDN. The issue raised by this ticket is that "mange.py test" would fail to run tests when you had contrib.auth in your INSTALLED_APPS. That is because [7716]

Re: Support for ON DELETE and ON UPDATE in foreign keys

El jue, 19-06-2008 a las 11:00 -0400, Michael Glassford escribió: > * If settings.DATABASE_HANDLES_ON_DELETE=True, the SQL that is generated > by manage.py contains ON DELETE clauses where on_delete= is > specified. > > * If settings.DATABASE_HANDLES_ON_UPDATE=True, the SQL that is generated >

Re: RFC: Django 1.0 roadmap and timeline

El lun, 16-06-2008 a las 10:00 -0700, [EMAIL PROTECTED] escribió: > I really like the roadmap, but I'm wondering where the docs- > refactoring work comes in? It in "Maybe" features, second from the bottom on http://code.djangoproject.com/wiki/VersionOneFeatures -- http://www.marcfargas.com --

Re: RFC: Django 1.0 roadmap and timeline

El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió: > A bug/feature keyword won't > give you anywhere as much attention, but it will help us filter out > features from the list of work we need to focus on. I took the other way around, I'm adding the keyword "post10" for tickets

Re: Translation tickets

El dom, 15-06-2008 a las 22:54 +0200, Ludvig Ericson escribió: > Well, the thing is, we really want two eyes on tickets regarding > translations. It doesn't have to be a maintainer, but anyone who can > assure that some translations don't say "Cancerface" in the target > language. So, I

Translation tickets

Hey, There a few translation tickets (5 right now). Normally Malcolm takes care of all translation stuff that has not been delegated (you know, some translations are directly dealt by its maintainers). But as Malcolm is offline those tickets are there hoping to get into at some point in time.

Re: RFC: Django 1.0 roadmap and timeline

El dom, 15-06-2008 a las 14:11 +0800, Russell Keith-Magee escribió: > Based purely upon the ticket titles, they certainly sound like good > candidates. Thanks, my criteria is now completely flawed! ;) > You have been doing a lot of good triage work over the last few days Thanks again :) > have

Re: RFC: Django 1.0 roadmap and timeline

El sáb, 14-06-2008 a las 13:28 -0700, Charlie escribió: > I'm curious if there are any plans to support simple urls for "RESTful > resources" in Django, especially before the 1.0 release. It's not on the roadmap to 1.0 so it won't be there, there's a project around that see this list archives on

Re: RFC: Django 1.0 roadmap and timeline

Hi there, El mié, 11-06-2008 a las 21:03 -0500, Jacob Kaplan-Moss escribió: > * Two beta releases. > > All "maybe" features must be completed by the first beta; after that, > Django will enter feature freeze for about a month while we kill bugs. > > * At least one -- and hopefully only one

Triaging: Google's AppEngine support policy

Hi there, I'm trying to clean the Unreviewed tickets list a bit (from 108 to 73 right now) and I'm now at #7008. #7008 is about "Session backend for Google's App Engine" and before moving it to Accepted, Design Decission or wontfix I thought it was worth bringing this here. Althought, right now,

Claiming tickets (was: Django development staleness)

El mié, 11-06-2008 a las 08:45 +0800, Russell Keith-Magee escribió: > Trac contains all the information you need. If a ticket is open and > it's not assigned to somebody, then it's a safe bet that nobody is > looking at it. If it _is_ assigned to somebody, but there hasn't been > any activity

Re: get_{next,previous}_by_someDateField()

El mar, 10-06-2008 a las 09:54 -0400, Karen Tracey escribió: > I agree the error message could be better. > Thanks for the elaborate and concise answer, I'll work on a nicer error message then ;) Should the error raise a ProgrammingError or ValueError ? -- http://www.marcfargas.com -- will

get_{next,previous}_by_someDateField()

Hi, There are two things about get_NEXT/PREVIOUS_by_DATEFIELD() which I'm not sure if a bug should be filled agains (almost sure anyway). given a simple model like: class TestModel(models.Model): date = models.DateTimeField(auto_now_add=True) m = TestModel()

Re: About an UPDATE.txt file

El sáb, 07-06-2008 a las 19:53 -0500, James Bennett escribió: > On Sat, Jun 7, 2008 at 7:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Right now Backwards Incompatible changes are documented in a wiki page, > > with some disadvantages: > > And in the release notes

Re: About an UPDATE.txt file

El sáb, 07-06-2008 a las 17:54 -0700, [EMAIL PROTECTED] escribió: > I'd be +1 on this, the only downside is that whoever commits the patch > will need to insert the correct revision at commit time. You can't do so unless you do svn info, svn commit both very fast. That would go on a new section

About an UPDATE.txt file

Hi there, Right now Backwards Incompatible changes are documented in a wiki page, with some disadvantages: * There's a reference in documentation to the wiki (install.txt:182) * When commiting those changes the wiki has to be updated by hand. * Some people expect either a

Re: Easier URL patterns

> El mar, 08-04-2008 a las 04:27 -0500, James Bennett escribió: > Or people could go learn from one of the many thousands of regex > tutorials that's already been written? There's a point at which we > have to assume that people are willing to help themselves out a bit by > learning Python and

Re: Easier URL patterns

El mar, 08-04-2008 a las 10:09 +0200, David Larlet escribió: > >>url(r'^(?P[-\w]+)/$', myview), > > > > Note that this example is more complicated than it needs to be. I'd > > write it like this: > > > >(r'^([-\w]+)/$', myview) > In this case, what about a default dictionary of popular

Re: Model Inheritance

Model inheritance is not there yet. You can take a look at the queryset-refactor branch, since Changeset 7126 moder inheritance begun to take shape. The changeset also includes documentation about that. You can either use this branch or wait until it gets merger to trunk.

Re: #6320, clarifications on contributing.txt

El jue, 24-01-2008 a las 20:16 +0900, Russell Keith-Magee escribió: > Thanks for taking the lead on this. Suggestions on how to improve > documentation are always welcome, especially when they are specific > suggestions, backed up by evidence of the existing inadequacy (as you > have done with

#6320, clarifications on contributing.txt

Hi there, A few days ago I filled a bug on "contributing.txt" (#6320) [0] about clarifying what triagers are, what volunteering means and who should do what. That was mostly motivated due some tickets in which volunteers marked as Ready for checking and "more official" triagers prefered this

Re: Feature Request: "Abstract Model"

am > following the "DRY" principle). > > Is it possible to give any prediction when this great stuff will be > checked in? Thanks a lot. > > Wanrong > > Marc Fargas wrote: > > Hi Wanrong, > > Maybe you could live with something like: > >

Re: Feature Request: "Abstract Model"

Hi Wanrong, Maybe you could live with something like: class common(models.Model): ... Meta: create_db_schema = False class Model_B(models.Model): ... Meta:

Re: Is there a simple way I can find which files still use oldforms, and have no patch?

grep -n -R "from django import forms" grep -n -R "import django.forms" Hope it help ;) El sáb, 05-01-2008 a las 00:41 -0800, shabda.raaj escribió: > I submitted ticket and patch for http://code.djangoproject.com/ticket/6318, > but that is a duplicate of http://code.djangoproject.com/ticket/6083

Re: Django internal tests

unning a single test see: > > http://www.djangoproject.com/documentation/contributing/#running-the-unit-tests > > Michael Trier > blog.michaeltrier.com > > On Dec 1, 2007 3:53 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Hi people, > > When one "n

Django internal tests

Hi people, When one "newbie" wants to create a patch with tests for Django (which are a requirement for every ticket) he/She can get a bit confused. Maybe one knows how to write tests for his/her own applications so the first thing to try will be something like: django//tests.py this is

Re: ANN: Django sprint, December 1st

Hi ppl, I was looking at SprintIdeas on the wiki and did a bit of cleanup at the bottom. I think we could find a more "agile" way to handle the "Results" part of the page, the way it's done now means that when you edit the ticket during the sprint you then have to edit the wiki page to reflect

Re: Django Week in Review -- ATTN: Adrian Holovaty

Hi, Just a quick note, on: [...] [5502] -- Stefane Femgier submitted a patch that correctly sets the mime-type for admin media content, and was integrated into the trunk the week. [...] Maybe it should read "into trunk this week" not sure about the "the trunk" but "the

Re: [Triagers/Core] About Stale Tickets

El mar, 29-05-2007 a las 10:53 +1000, Malcolm Tredinnick escribió: > I didn't respond to your first email about this over the weekend, > because the reply I originally wrote wasn't particularly polite. Thanks for not sending that one then ;) > At some point, you have to accept that this ticket

Re: MEDIA_URL template tag/context processor/etc again

El mar, 29-05-2007 a las 08:15 +0800, Russell Keith-Magee escribió: > I make that 5:3 - and not wanting to put a jackboot down on the throat > of democracy, but #1278 has the support of 4 core developers, > including the BDFL. I never was good at maths :) And I didn't perform a really well

Re: MEDIA_URL template tag/context processor/etc again

My count at the end of the thread is: #1278: 4 votes #4105: 4 votes So I thow a coin to the air... oh, it felt off the window! As the main issue with having media_url in templates what the context bloat we could go for the #4105 approach, but as recently Adrian told he's fine on

[Triagers/Core] About Stale Tickets

Hi there, Since we got the triagers system patches and bugfixes are moving much faster than before but there are still somethings that get stuck, specially on the "Design Decission Needed" state. In theory, if I got it right, triagers set this state when they think that the scope of a ticket

Re: [DjangoProject.com] Volunteering for "Week in Review" postings

El vie, 25-05-2007 a las 07:25 -0500, Clint Ecker escribió: > Hey everyone, > maybe we can work out a nice system for sending the author of these > posts (ostensibly me) pointers to cool articles/news that might > normally be missed and/or come to some consensus of what would be a > good schedule

PostgreSQL Schemas, again

Hi there, Ticket #1051 is stalled in "Design decision needed" since a long time ago (since January). That ticket only deals with the thing of allowing the user (not the developer) to ser a specific search_path in postgresql from a setting in settings.py, it does not introduce any backwards

Re: MEDIA_URL template tag/context processor/etc again

El vie, 25-05-2007 a las 03:20 -0500, Adrian Holovaty escribió: > Given the frequency of this request, I'm OK with adding a context > processor in django/core/context_processors.py that sets a "MEDIA_URL" > variable in the context. I'm also OK with having that be in the > default

Re: problems serving PDF file from view

On 5/21/07, Curtis <[EMAIL PROTECTED]> wrote: > An alternate solution: > > response = HttpResponse(pdf, "application/pdf") > response['Content-Disposition'] = 'attachment; filename=%s.pdf' % > filename > return response I use a similar approach to output PDF's on our intranet

Re: why index all SlugFields ?

Maybe because there is a high change that you will try to find rows based on this SlugField, so in common cases this INDEX will be nice. Also it's documented on http://www.djangoproject.com/documentation/model-api/#slugfield that this field has an implicit db_index=True, BUT you can always pass

Re: contrib proposal: django-values

Hi, On 4/8/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > * The name "values" is a bit too abstract -- it took me a while to > figure out exactly what this framework *does*. Maybe something like > "editable constants" or "model-specific options" would be more clear. Isn't a constant

Re: Trac Timeline RSS feeds

Maybe you can't find it because it's "wontfix" :)) http://code.djangoproject.com/ticket/3326 On 3/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-03-29 at 21:05 +0800, Russell Keith-Magee wrote: > > Hi all, > > > > I just noticed that my RSS reader has stopped providing

Re: Support for a binary storage field?

Hi, If you provide a BinaryField it's just a matter of time that "hacks" will start to go out on blogs, the wiki or even django-users to get ImageField and FileField on the database (there's a hack on this already), maybe it's 99% bad but if those fields are provided inside django it will be much

Re: django documentation - editing

Uhm.. when did comments disappear? They're nowhere now! It's nicer that way :) Forget my last comment! On 3/27/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > w0w, > That's really **cooler** than the previous method. I always wondered how > often were the on-line docs up

Re: Constraints and MySQL

Hi, On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > Because the other Databases have 'limitations' or 'features' or > 'defects' that MySQL might not have or whatever. Django is, as I have > been told, database independent. And Django is working fine with > MySQL, lets keep it that

Re: Constraints and MySQL

Hi, On 2/28/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: [...] > Either way, the problem/limitations > with MySQL needs to be mentioned in the documentation (both > serialization and fixtures). Yes, in really big red letters, we could add a directive for the documentation rst for "thinks

Re: Newforms styling suggestion

By container we should mean the most top element so it should be the or that has the label and the input below it ;) On 2/16/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Marc Fargas Esteve wrote: > > You could set the additional class to the container so you can

Re: Newforms styling suggestion

You could set the additional class to the container so you can use simple CSS selectors to apply different styles to any element from the container and inside it. Setting the class on the label or the input field would not allow to modify the container. My 0.02, Marc On 2/16/07, Waylan Limberg

Re: Should newforms security fixes be posted to django-announce?

Hi, inline On 2/9/07, James Bennett <[EMAIL PROTECTED]> wrote: [...] > But on the other hand, if somebody does decide to go a little while > without an "svn up", it'd be nice to have this announced so they know > that they should update (though I have my doubts about how many people > actually

Re: Please encourage PsycoPG 2 usage (not 1!)

And I use windows 3.1 'cause I prefer it! Just joking ;) But psycopg1 is obsolete so newcomers should be recommended to version use 2 unless there are still outstanding issues with it. They can always go to psycopg1 if they want ;) On 2/9/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > >

Re: Django Builbot (was: dbsync for mysql lacks...)

Hi, inline On 1/31/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > The Django buildbot slave is currently running inside a Solaris 10 > zone so it is virtualized...kind of. > > Let me clarify that testing python 2.3 and 2.4 would require a > separate buildbot master than pybots unless you can

Django Builbot (was: dbsync for mysql lacks...)

[note: maybe this message appears twice as I sent it with the wrong reply-to and google-groups likes to reject it, if so, sorry ;) ] Hi Matthew On 1/30/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > I run the django pybot. It wouldn't be difficult to add other backends > to the tests and is

Re: Django Builbot (was: dbsync for mysql lacks...)

On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > Marc Fargas Esteve: > That sounds interesting. (Did I mention that it should run python > versions 2.3, 2.4 and 2.5? ;-) As Matthew said this could be done with separate buildbots or slaves running different jobs. > I w

Django Builbot (was: dbsync for mysql lacks...)

Hi, inline On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: [..] > I'm now dreaming of a test service that would automatically run the > testsuite for a given patch (or multiple patches) with all supported > database backends ... Also thought about that, getting up a buildbot for testing

Re: Minimum MySQLdb version? (#2765, #3279)

err.. sorry, forgot the links for lazy people: [1]: http://code.djangoproject.com/ticket/2765 [2]: http://code.djangoproject.com/ticket/3279 On Jan 26, 12:10 am, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote: > Hi there, > The tickets #2765[1] and #3279[2] are about t

Re: triage: Which "state" for #3279

Thanks Michael for the explanation, I took the ticket as example until you pointed me to comment #9 :) Cheers, Marc. On 1/25/07, Michael Radziej <[EMAIL PROTECTED]> wrote: [...] > This ticket is a bad example. It should be open, and it is only > closed since reopen does currently not work. > >

triage: Which "state" for #3279

Hi, In the nice graphic on http://www.djangoproject.com/documentation/contributing/#ticket-triage #3279 would go from "Unreviewed" to the left to "worksforme" as the resolution, but what Triage State would it get? "Unreviewed" is not true, as it has been reviewed, but it's not "Accepted" either

Re: triage: one third done

Really nice work, congratulations! ;) On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > just to give you an idea how fast we proceed: currently 228 out of > 655 open tickets have been reviewed, and that does not count all > those that got closed during triage! Isn't that nice? >

[triage] Howto emphasize a ticket

Hi there, The triage system is really nice! but there's just one thing, with the removal of priorities when a core developer goes to see the "Read for check-in" tickets it has no way to know that some of those tickets should be taken ASAP, for example: #3336 which solved broken links in