Localflavor "US state" field choices

Over the past few months we've had a few back-and-forth tugs in the ticket tracker, and a couple of commits, related to the choice list for ``django.contrib.localflavor.us.forms.USStateField.`` Relevant background: * First, ticket #8425 asked for several choices to be removed, on grounds that

Re: Is this true. that django really takes a lot of memory?

On Tue, Feb 17, 2009 at 7:49 PM, Malcolm Tredinnick wrote: > I'd be somewhat against this, I think. It's *very* easy to reuse > querysets and inadvertently cause extra database queries. Unless you're > using really huge querysets, the memory usage is not going to kill

Re: App Engine port

On Fri, Feb 6, 2009 at 8:51 AM, David Stenglein wrote: > I have to ask a question here. Why is there such reticence regarding > App Engine? I'm curious as to what reticence you think there is; since, as Russell said, code to get a straight Django with all features

Re: How to help with doc?

On Fri, Jan 16, 2009 at 1:53 PM, Geoffrey Ducharme wrote: > From what I gather, the documentation effort have been mostly voluntary and > not well organized. For example, I don't think there is a mailing list for > documentation feedback. People like you seem to pop

Re: deploying django project

This question most properly belongs on the django-users list. Also, you may want to consider spending some time with the Django documentation (in particular, searching the docs index for the word "deploy"). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Re: Problem with ORM

On Thu, Jan 15, 2009 at 2:58 AM, Jan Bednařík wrote: > this is happening, because Django ORM is not working as what you > expect from ORM. > > In real ORM, this: No... I don't think you mean "real ORM", I think you mean "identity-mapping ORM". Those terms are not the

Re: Distributed workflow and the woes of slow testsuite

On Mon, Jan 12, 2009 at 6:53 AM, mrts wrote: > What if we try to be nice to ourselves and get #8138 and something in > the lines of http://oebfare.com/blog/2008/mar/25/faster-django-test-suite/ > into trunk ASAP What if we pay attention to the work that's been done on that

Re: manage.py has x flag turned off

On Sat, Dec 27, 2008 at 4:18 PM, bedros <2bed...@gmail.com> wrote: > my apologies, django 1.0.2 final does not have x turned on for > manage.py. However, the book I'm reading "Python Web Development with > Django" has the x turned on. It must be that they used a version > before 1.0.2 final. (it

Re: Perl port of the django template system.

On Fri, Dec 26, 2008 at 11:36 AM, Maluku wrote: > Kind of different question: Why is there no {% else %} in {% ifchanged > %}, I think it might be a help to some people. Because it wouldn't make any sense; the point of 'ifchanged' is to say "I have a special thing

Re: Perl port of the django template system.

On Tue, Dec 16, 2008 at 11:04 PM, Eugene Lazutkin wrote: > Some people are blessed with being naturally confused without external > factors. Indeed. Documenting that something implements the same format as Django templates will only confuse people who were already

Re: Perl port of the django template system.

On Tue, Dec 16, 2008 at 10:32 PM, alex.gay...@gmail.com wrote: > I am not a legal expert(that's Justin's job ;-) ), but there is a > precedent for a derivative template language going by the same name, > Dojo also implements the Django template language and calls it just >

Re: Default manager

On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato wrote: > I don't see any downside in this proposal. His proposal seems to center around forcibly making "objects" *always* be a manager returning an unfiltered QuerySet, so I'm not sure where it'd allow for that. And

Re: Default manager

On Mon, Dec 15, 2008 at 4:51 AM, Alex Rades wrote: > my understanding about custom managers is that if you want to define a > custom manager, you also HAVE to remember to define the "objects" > manager first, otherwise some parts of django (eg. admin) will not > work. No, if

Re: How do you handle cascading deletes in your production apps?

On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield wrote: > +1. Definitely need some kind of cascade=False option somewhere. I'd > argue it should be the default. I have some production horror stories > which I'm sure I don't need to share. Keep in mind there is some prior

Re: IDN (Internationalized Domain Names) support for EmailField and URLField

On Fri, Dec 5, 2008 at 10:55 PM, UloPe <[EMAIL PROTECTED]> wrote: > I created a ticket for this and added a patch which adds this > fuctionality: > http://code.djangoproject.com/ticket/9764 I have created a reply to your email pointing out that anyone who's interested is likely already

Re: logout() method for custom authentication backends

On Mon, Dec 1, 2008 at 8:10 AM, David Reynolds <[EMAIL PROTECTED]> wrote: > That doesn't help if you want to continue using the login/logout views > from django.contrib.auth.views Since you can drop callables directly into URL patterns, you can write a decorator which does what you need, import

Re: Proposal: deprecate and remove django.utils.simplejson

On Mon, Dec 1, 2008 at 12:45 AM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > I have to say I agree with Malcolm. I don't believe we are currently > hampered in any real way by bundling an old version of the SimpleJSON > library, and it doesn't take that much effort to update the bundled >

Proposal: deprecate and remove django.utils.simplejson

Apologies for bringing this up past the 1.1 feature deadline, but since this isn't a feature perhaps it'll be OK :) Currently, Django bundles a copy of simplejson[1], at django.utils.simplejson. We use this solely in the serialization system to support dumping to and loading from JSON fixtures.

Re: Dropping Python 2.3 compatibility for Django 1.1

On Thu, Nov 27, 2008 at 7:20 AM, Tim Chase <[EMAIL PROTECTED]> wrote: > So I'm somewhere between -0 and -1 on the voting scale regarding > forced/long-range Python-version deprecation. But when a version > becomes sufficiently dead weight, slowing down Django's progress > like 2.3 seems to be

Re: Dropping Python 2.3 compatibility for Django 1.1

Apologies for the length of this email, but I've been holding back on my thoughts about Python version compatibility for a while, mostly due to the fact that: 1. Until recently, we didn't have a stable Django release series on which to begin considering the process of dropping support in

ANN: Django 1.0.2 released

Tonight, to clear up some problems with the packaging of the Django 1.0.1 release from Friday, we've released Django 1.0.2; once again, this is a bugfix-only release, and is a recommended upgrade for anyone targeting or using Django 1.0 or Django 1.0.1. Weblog entry announcing the release is

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > I'm always wondeing how it's possible that Django creators don't use > django in ways that are written in django documentation. That leads to > misunderstanding in expectations, and should explain why some tickets > don't

Re: ANN: Django 1.0.1 released

On Sun, Nov 16, 2008 at 5:42 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I'll defer to James to make the final call, but I'd prefer to do this > and release 1.0.2 on Monday or Tuesday with a note that it's basically > 1.0.1 plus the GeoDjango stuff we forgot and a couple of new bug fixes >

Re: ANN: Django 1.0.1 released

On Sat, Nov 15, 2008 at 8:42 PM, James Bennett <[EMAIL PROTECTED]> wrote: > 1. When I rolled the release last night, I did 'python manage.py > sdist' to generate the package, then uploaded it to the > djangoproject.com server. (and obviously I meant 'setup.py sdist') -- &qu

Re: ANN: Django 1.0.1 released

On Sat, Nov 15, 2008 at 7:48 AM, leonel <[EMAIL PROTECTED]> wrote: > Ive downloaded the tar.gz from > http://www.djangoproject.com/download/1.0.1/tarball/ > > and the md5sum does not match the md5sum from: > http://media.djangoproject.com/pgp/Django-1.0.1-final.checksum.txt OK, so here's what

ANN: Django 1.0.1 released

Tonight we've released Django 1.0.1, a bugfix release in the 1.0 series containing improvements and fixes since the 1.0 release. This is a recommended upgrade for anyone currently running Django 1.0. The blog entry announcing the release is here:

Re: 1.1 feature: unify access to response.context in test client

On Sun, Nov 9, 2008 at 2:25 PM, Gábor Farkas <[EMAIL PROTECTED]> wrote: > does this mechanism work with contexts with integer-keys? A context variable can't really be an integer, so far as I can tell... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Re: 1.1 feature: unify access to response.context in test client

On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > However, to clarify - are you talking about a backwards incompatible > change, or are you talking about putting a backwards compatible layer > in place that tries to tell the difference between the two modes of >

Re: 1.0.1 release blockers?

On Tue, Nov 4, 2008 at 8:04 AM, mrts <[EMAIL PROTECTED]> wrote: > Except that most of the tickets that have been brought up in this > discussion already have patches, they just don't get the needed > attention from core devs. And if you feel that's the case, by all means bring them up. But there

Re: 1.0.1 release blockers?

On Sun, Nov 2, 2008 at 5:54 AM, Tai Lee <[EMAIL PROTECTED]> wrote: > There's still no comment in the ticket from a core developer or > anybody else, though. As this is a simple bug fix, can I (as the > reporter) mark this ready for checkin, as there is a patch with tests? You do know that Karen

ANN: Django 1.0.1 beta available

See the weblog entry: http://www.djangoproject.com/weblog/2008/oct/31/101-beta/ And the downloads page: http://www.djangoproject.com/download/ As previously mentioned, this is mainly a preview to let people get a feel for what's been fixed/improved in the 1.0.X line since the 1.0 release, and

Re: 1.0.1 release blockers?

On Fri, Oct 31, 2008 at 5:38 AM, mrts <[EMAIL PROTECTED]> wrote: > There has been much reluctancy in letting triagers tag and prioritize > 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we > perhaps discuss what are the things that really should be fixed before > it is released? We

Re: Absolute paths in settings.py

On Thu, Oct 30, 2008 at 3:20 PM, Rob Hudson <[EMAIL PROTECTED]> wrote: > Not necessarily true. If this code were in the settings.py from the > project_template it would get laid down in your project when you ran > django-admin.py startproject, which is, I think, the appropriate place > for this

Re: Who can set "ready for checkin"?

On Tue, Oct 28, 2008 at 7:33 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > Who can set "ready for checkin"? You know the answer: Ticket triagers > > But who are they? I have some tickets which are only small changes incl. > unittest. Generally speaking, it should be set by: 1. Someone who is

Re: Proposal: AnonymousUser that you can set specific permissions for

On Fri, Oct 24, 2008 at 9:40 PM, Dj Gilcrease <[EMAIL PROTECTED]> wrote: > This patch allows the creation of a user with the username > BuiltinDjangoAnonymousUser, and will return an instance of that User > (if it exists) instead of the AnonymousUser class. I added checking in > the actual user

ANN: Initial release timelines for Django 1.0.1 and Django 1.1

(putting on release manager hat...) We've just put up an entry over at the official Django project blog with details of the timelines for Django 1.0.1 and Django 1.1: http://www.djangoproject.com/weblog/2008/oct/24/upcoming-releases/ Please bear in mind the immediate consequences of these

Re: GET requests should not alter data?

On Fri, Oct 17, 2008 at 7:10 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > To reiterate, I am proposing: "avoid, and if not possible, document" for DB > updates in GET, are you really saying you are against this? Is your logical > position "encourage" or "don't care/document"? To reiterate, I

Re: GET requests should not alter data?

On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Either this becomes a django standard, every code that might update database > on GET doing something like: > > connection.use_master() > try: > ... # something that updates db >

Re: GET requests should not alter data?

On Thu, Oct 16, 2008 at 7:11 AM, Rajeev J Sebastian <[EMAIL PROTECTED]> wrote: > Without trying to read deeply between the lines, the thread seemed to > come to a point where the one choice would be to document the cases > where in the core (i.e., django+contrib) a GET request could cause a > db

Re: Custom submit buttons on admin form

This question belongs on the django-users list; in the future, please keep in mind that this list is for discussion of actually developing Django itself, while django-users is for discussion of how to use Django. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Re: "things are ready" signal?

On Wed, Oct 1, 2008 at 4:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > 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. Just after *what* is ready, precisely? After "import django" has succeeded?

Re: ANN: 1.0.X branch created; trunk is open for features

On Wed, Oct 1, 2008 at 4:07 AM, Richard Davies <[EMAIL PROTECTED]> wrote: > Perhaps it's now time for a '1.0.1' milestone in the ticket tracker, > to nominate those tickets which are simple bug fixes against '1.0'? No. Right now any bug at all that was present in 1.0 is a candidate for fixing.

django.VERSION changes committed

In revisions 9102 and 9103, I committed the changes to django.VERSION and django.get_version() announced previously[1]. To recap: The VERSION tuple in trunk is now (1, 1, 0, 'alpha', 0), and get_version() in trunk now prints "1.1 pre-alpha SVN-9103". The VERSION tuple in the 1.0.x branch is

Re: Postgresql transaction aborts, despite being in autocommit mode

On Mon, Sep 22, 2008 at 9:11 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > However, Django also misuses transactions in other cases (exactly the > ones you mention). A transaction does not guarantee consistency of > multiple operations, at least not in the default READ COMMITTED >

django.VERSION changes

A while back I proposed changing the way the ``django.VERSION`` tuple is set up. That discussion petered out a bit, until I brought it up with Jacob just before the 1.0 release. At the time, we felt it wasn't possible to do it before we rolled 1.0 (this was, due to my absent-mindedness, about ten

Re: Signal Connection Decorators

On Sat, Sep 13, 2008 at 8:10 AM, zvoase <[EMAIL PROTECTED]> wrote: > Couldn't we move this discussion to the ticket on Django's Trac? Preferably not; it's far easier to keep track of a threaded discussion here on the mailing list, as opposed to trying to follow it in the ticket. --

Re: I want a pony: Django Cheeseshop

On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote: > * create a central app index à la Cheeseshop Doesn't the Cheese Shop already exist? > * create an automated system similar to easy_install for installing > apps from > o that central repository "easy_install

Re: djangoproject.com/documentation/ redirected

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 make docs.djangoproject.com redirect there instead of /en/dev/ ;)) ( > #8992 ) Yes, and that's holding a bit until we get a

Re: Forms and edition of an object : non-pythonic default behaviour

On Sat, Sep 6, 2008 at 8:40 AM, Denis Frère <[EMAIL PROTECTED]> wrote: > Why LinkForm(request.POST, instance=link) doesn't behaves like > link.update(request.POST) ? > Is it a will or an "omission" ? it doesn't behave that way because it'd make no sense to behave that way; if there's a field in

ANNOUNCE: Django 1.0 released

The Django team is pleased to announce the release of Django 1.0 this evening: Download: http://www.djangoproject.com/download/ Release notes: http://docs.djangoproject.com/en/dev/releases/1.0/ Have fun with it, and we'll see you in a few days for DjangoCon. -- "Bureaucrat Conrad, you are

ANNOUNCE: Django 1.0 release candidate now available

We've just put up the package for the first Django 1.0 release candidate; this package contains all of the progress made on Django through the alpha and beta releases, and is fairly close to the final Django 1.0 release. It's still not recommended for production use, but we do encourage everyone

ANNOUNCE: Security updates for Django trunk, 0.96, 0.95 and 0.91

are a hosting company which officially supports Django as an option for customers, and you did **not** receive an advance notification of this issue, please contact Django's release manager (James Bennett, james at b-list dot org) as soon as possible so that you can be added to the list of known

Re: request_started signal

On Tue, Aug 26, 2008 at 8:05 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have some code for processing the urlsconf so signals seems like the > obvious tool. Apparently there is on server_started signal firing when > configuration is complete(that would be a very nice signal to get into

Re: old docs not opening

On Tue, Aug 26, 2008 at 4:58 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Giving 404. Known issue or I should file a bug? Due to limitations of the old docs system, there are quite a few such links (typically due to documentation which existed in one release but not in another). There's no

Re: validator_list still in docs

On Mon, Aug 25, 2008 at 6:57 PM, Michael Hrivnak <[EMAIL PROTECTED]> wrote: > That is neither a direct nor indirect replacement for model-level validation. > Many applications receive input from sources other than forms. Validation at > the form and model level are both valuable, but for

Re: validator_list still in docs

On Mon, Aug 25, 2008 at 10:12 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > So there isn't a direct replacement for validator lists in 1.0. (other than just setting up the form used for your model in the admin to have the validation you want, which isn't terribly hard and is how this sort

Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers

On Sun, Aug 24, 2008 at 2:11 AM, Karen Tracey <[EMAIL PROTECTED]> wrote: > I don't understand this argument. At some point fixing this general issue > is going to have to involve a piecemeal change of each instance where > exceptions are currently swallowed. (Or at least each instance where the

Re: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers

On Sun, Aug 24, 2008 at 12:53 AM, Jonas Pfeil <[EMAIL PROTECTED]> wrote: > P.S.: I should have brought this up here earlier instead of causing a > somewhat lengthy discussion on IRC, sorry for that. I hope James > doesn't hate me after this ;) I stand by what I said in the dev channel yesterday:

Re: Please force ticket 8367 to inclusion.

On Fri, Aug 22, 2008 at 4:08 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > 1) You have less than 2 weeks left and still 188 tickets marked with > 1.0 tag Correction: we have 153 tickets open with the 1.0 milestone. Not bad for eight hours' work, IMHO, and we've still got a couple sprints left to

Re: Please force ticket 8367 to inclusion.

On Fri, Aug 22, 2008 at 4:08 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > Really? Dude. Don't be that guy. OK? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are

Use admin.autodiscover() by default?

As of the newforms-admin merge, the IRC channel is seeing a sudden rush of folks who try the tutorial and complain because the admin doesn't work. And they're right, because as written the tutorial sets up the admin in such a way that it's never aware of any models being registered -- including

Re: DjangoCon

On Fri, Jul 18, 2008 at 1:59 PM, Frijole <[EMAIL PROTECTED]> wrote: > Does anyone know how to get tickets for the DjangoCon, I though they > were releasing them today? When the time comes there will be a large and loud public announcement that you will not be able to miss. -- "Bureaucrat

Re: Inquiry

This list is not for general usage questions; rather, it is for discussion of the development of Django itself. Please keep usage discussion on django-users. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~

Re: MS SQL pyodbc backend update to trunk

On Tue, Jul 8, 2008 at 8:26 AM, vcc <[EMAIL PROTECTED]> wrote: > I just updated this backend, it's look like everything work fine for me. I > have some projects working with this backend, I'll keep improve it. Please > check the patch in the attachments. As Russ, and the many previous threads

Re: #7666: Default managers should not restrict access to single related objects

On Mon, Jul 7, 2008 at 8:29 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Currently, ReverseSingleRelatedObjectDescriptor uses _default_manager, > which is the problem (line 239 in django/db/models/related/fields.py). > One clean solution would be to give each model a _pristine_manager >

Re: Community representation, or, #django user "Magus-" needs to go far away

On Wed, Jun 25, 2008 at 4:21 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > Specifically, I'd like you to note interactions with user "Magus-" > (with trailing dash). Four points: 1. His name is Collin. 2. He's one of the channel ops. 3. As someone who hangs out in the channel pretty much 24/7 I

Re: The Model.default_manager concept

On Mon, Jun 16, 2008 at 1:48 PM, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > You could as stick them in a single manager as well (and wouldn't > have to remember which method is available via which manager). > My point is that one manager per model would be enough to do anything > you can do

Re: The Model.default_manager concept

On Mon, Jun 16, 2008 at 9:44 AM, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > If you're just want different querysets you can use something like > this: http://dpaste.com/53948/. Or I can use managers and also add other supporting methods (which I also often do). -- "Bureaucrat Conrad, you

Re: RFC: Django 1.0 roadmap and timeline

On Mon, Jun 16, 2008 at 10:22 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Has anyone else noticed that development progress seems to have > exploded since this thread was created? In the weeks/months after the > qs-rf merge, several days would go by when there wasn't a single > change

Re: The Model.default_manager concept

On Mon, Jun 16, 2008 at 9:22 AM, Johannes Dollinger <[EMAIL PROTECTED]> wrote: > Is there a rationale for multiple managers per model? Yes, and I at least use them all the time. For example, I'll often have one manager that does no special filtering, and another that only returns things with a

Re: RFC: Django 1.0 roadmap and timeline

On Thu, Jun 12, 2008 at 11:10 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > And this is great of course. But having to develop externally away > from the many eyes of the Django community is sort of an impairment. > It's a lot easier to get traction on a project that is in the Django > repo

Re: RFC: Django 1.0 roadmap and timeline

On Wed, Jun 11, 2008 at 11:17 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have to ask why must Django prevent work in this regard? To be perfectly fair, it's not really "prevented". Django supports the use of database backends not defined in Django itself, so third-party development of

Re: Django releases

On Mon, Jun 9, 2008 at 3:57 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote: > As mentioned in my previous post, if it's indeed three months, I agree, > but if it's only "hopefully" three months, then do we want to end up six > or nine months out still waiting for 1.0 to land "in a couple months?"

Re: Django development staleness

On Tue, Jun 10, 2008 at 5:46 PM, Edgars Jēkabsons <[EMAIL PROTECTED]> wrote: > I'd like to remind everyone involved that Django development really > seems to stale when looking at active tickets. > > There are 1116 active tickets right now, 341 of them haven't even been > reviewed and 201 of the

Re: Django releases

(incidentally, for anyone who's joining in and wants to genuinely add to the discussion: starting your reply by calling one of the developers a douchebag causes me, at least, to stop listening and simply assume you're a troll. The more you know...) -- "Bureaucrat Conrad, you are technically

Re: Django releases

On Tue, Jun 10, 2008 at 12:24 PM, testguy56 <[EMAIL PROTECTED]> wrote: > Wow, starting a reply like that makes you sound like an elitist douche > bag. I love the smell of troll in the morning, don't you? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Re: Understanding HTML, XML and XHTML

On Tue, Jun 10, 2008 at 10:38 AM, Rob Hudson <[EMAIL PROTECTED]> wrote: > I am curious if anyone thinks having support for outputting html4 > compliant markup in Django is a good thing? And if so, what can I do > to help make that become a reality? I for one would appreciate it, because I'm

Re: Django releases

On Mon, Jun 9, 2008 at 2:47 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote: > I agree with the sentiment of this, but we've passed the point where > it's a useful argument. I'll concede that if you'll concede that we've also passed the point where issuing interim pre-1.0 releases offers any real

Re: Django releases

On Mon, Jun 9, 2008 at 11:54 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > I believe it's one official release back. James will know better. For security we patch trunk, of course, as well as current stable release plus the two previous releases. This means we currently provide security updates

Re: Django releases

On Mon, Jun 9, 2008 at 1:50 AM, Ashish <[EMAIL PROTECTED]> wrote: > In short all I am looking for is commitment to " freezing the scope, > publishing a plan and hitting it for 1.0 " That will greatly increase > the community's trust. Er. You linked to a well-known thread in which the plan for

Re: Django releases

On Sun, Jun 8, 2008 at 9:51 PM, Ashish <[EMAIL PROTECTED]> wrote: > my proposal is You do know that a list of what has to happen before 1.0, and a page listing the status of each item, has been available for quite some time, right? I > Lack of visibility on what is going on with 1.0 and over

0.96 tarball

Just a quick procedural thing: The 0.96.2 tarball created for the recent security fix was generated from the 0.96 setup.py script, which gets you the Django source tree but misses things like the documentation files that we distribute with Django. This has caused a couple of issues with

Re: Django releases

And for the record, I do think that *post-1.0* we should do more frequent releases, because it'll be quite a bit simpler to do at that point. I just think that right now it's not really worth the trouble; the same people who currently complain that they have to use a packaged release but want a

Re: About an UPDATE.txt file

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 when a new release happens. -- "Bureaucrat Conrad, you are technically correct -- the best kind

Re: Django releases

On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > * Start a "train release" schedule: schedule a couple of 1.0 betas, a > rc or two, and then a final release. Features that are done by the > dates get released, those that aren't, don't. Make these dates > aggressive

Re: Django releases

On Sat, Jun 7, 2008 at 11:48 AM, Rob Hudson <[EMAIL PROTECTED]> wrote: > I think the most often reason why I've heard is that it takes time to > create a release, post it, push security patches to it, etc. Which > makes sense, but at the same time there are a lot of valid points in > the blog

Re: flatpages and 404

Sigh. In [7555] I added a warning to the flatpages docs to hopefully silence this issue once and for all. Note that I did this not because I feel it's necessary or appropriate, but because I'm just getting really, really, really tired of people complaining about this. Can we please let this one

Re: Rethinking silent failures in templates

On Wed, May 14, 2008 at 8:58 AM, Simon Willison <[EMAIL PROTECTED]> wrote: > Silent errors are bad. If we were to remove them, how much of a > negative impact would it have on the existing user base? The impression I get is that a lot of people rely on silent *variable* failure, but very few

ANNOUNCE: Security bugfix releases

In accordance with our security policy[1], a set of releases is being issued tonight to fix a security vulnerability reported to the Django project. This message contains a description of the vulnerability, a description of the changes made to fix it, pointers to the the relevant patches for each

Re: Callable context variables do not get called during resolution.

On Fri, May 9, 2008 at 9:27 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > OK, I'll bite. I kind of doubt he rewrote the templating system in the > ORM, so you must be inferring that multiple database support was part > of the qs-refactoring. I just checked out trunk and I'll admit I'm > working

Re: Callable context variables do not get called during resolution.

On Fri, May 9, 2008 at 9:01 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > Now that Malcolm has subclassable models working, my number one > complaint is the templating system. Number two is single DB, but I can > work around that more easily. You probably should take a look at the ORM code. --

Re: /admin Cross-Site Scripting (XSS) issue!

On Wed, May 7, 2008 at 2:32 PM, Jan Rademaker <[EMAIL PROTECTED]> wrote: > > It does work, make sure you're not logged in. > > $ lynx -source -dump > http://localhost:8000/admin/%22%3E%3Cscript%3Ealert%283939%29%3C/script%3E/ > | grep alert > alert(3939)/" method="post" > id="login-form">

Re: API question for model saving

On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED]> wrote: > This may not directly solve the problems that are being referred to, but it > was a bug fix none the less, and I believe it is relative to the issue at > hand. I never said it wasn't a *possible* solution, I just said it

Re: API question for model saving

OK, so, we appear to have two camps: 1. People who think this should be handled by introducing one or more new methods to allow easy differentiation of the cases. 2. People who think this should be handled by adding new keyword arguments to save(). And, techncially, a third camp

Re: EmptyQuerySet

On Tue, Apr 29, 2008 at 5:00 PM, Luke Plant <[EMAIL PROTECTED]> wrote: > I've created a patch, which special cases EmptyQuerySet in a couple of > places, which seems to be the simplest way of doing it. I can commit > it myself, but I wanted to pass it by you first since I'm unfamiliar > with

Re: QSRF Related

On Tue, Apr 29, 2008 at 3:54 PM, David Cramer <[EMAIL PROTECTED]> wrote: > If I update from python 2.4 to 2.5 I can expect some trouble unless I know > what has changed. If I update trunk, which is what is considered the only > real version to use right now, I may encounter problems that I

Re: QSRF Related

On Tue, Apr 29, 2008 at 3:38 PM, David Cramer <[EMAIL PROTECTED]> wrote: > Yes im aware of the backwards incompatibility page but that mostly covers > the public api. A lot of time for our uses we have to go beyond just using > the public api. This is another situation where having more

Re: QSRF Related

On Tue, Apr 29, 2008 at 12:55 PM, David Cramer <[EMAIL PROTECTED]> wrote: > 2) I thought the very smple example explained it. Selecting on a > related field which already is present (so naming the select field > something that exists) would cause it to disappear, no errors, no > warnings.

Re: QSRF Related

On Tue, Apr 29, 2008 at 11:35 AM, David Cramer <[EMAIL PROTECTED]> wrote: > 2) Is the issue still present if you do > extra(select={'myforeignkeyname': 1}) ? Is the issue still present where you didn't explain what you were asking about? > 3) Most importantly. Is there a shiny new page in

Re: Model Inheritance in qsrf and User?

On Fri, Apr 25, 2008 at 10:23 AM, AmanKow <[EMAIL PROTECTED]> wrote: > Could you elaborate or point to elaboration on why non-abstract > inheritance is a bad fit for extending user? http://www.b-list.org/weblog/2007/feb/20/about-model-subclassing/ -- "Bureaucrat Conrad, you are technically

<    1   2   3   4   5   6   7   8   9   10   >