Re: ANNOUNCE: Django 1.0 released

On Sep 4, 1:07 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > The Django team is pleased to announce the release of Django 1.0 this evening +1! Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django develo

Re: Updated patch for ticket #6213

Anyone? Where's SmileyChris! :-) Thanks, Jason On Jul 12, 4:00 am, Jason Davies <[EMAIL PROTECTED]> wrote: > Hello, > > I recently attached an updated patch to #6213, "PREPEND_WWW and > APPEND_SLASH settings don't work with flatpages middleware"

Updated patch for ticket #6213

Hello, I recently attached an updated patch to #6213, "PREPEND_WWW and APPEND_SLASH settings don't work with flatpages middleware". The patch now contains unit tests demonstrating how it fixes lack of expected behaviour when FlatpageFallbackMiddleware or similar is used. The patch also fixes #6

Using RequestContext by default in default 500 handler

Dear all, I have several clients who make heavy use of MEDIA_URL for styling their sites. The pages generated by the default 500 error handler look rather ugly without any CSS or images, and the lack of branding confuses customers. The default error handler is easily overridden so that it tries

Re: Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

On Jun 19, 8:49 pm, Jason Davies <[EMAIL PROTECTED]> wrote: > 2. Utilise simple thread synchronisation mechanisms to control access > to the queryset in question.  This would only need to be done when > cache_choices is True, so in the usual case when it is False there > would

Re: Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

On Jun 19, 5:56 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > It seems to me you can just do: > if self.field.cache_choices: >     qs = self.queryset > else: >     qs = self.queryset.all() > for obj in qs: >     I thought about doing that, but then that would lead to the race conditio

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

On Jun 19, 3:04 pm, Steve Holden <[EMAIL PROTECTED]> wrote: > Well I guess the obvious (time consuming, painful) way would be to > validate the semantic integrity from Django in the back end. That could, > if automated, get horrendously time-consuming for even quite small > changes to the databas

Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

Hello, We have a reasonably high-traffic site, which started intermittently throwing "ValueError: generator already executing" errors under high load. This started happening after updating to a more recent trunk revision (r7601). After much digging around, it seems there is a race condition in

Re: Splitting django.newforms.models

Sounds like a sensible cleanup to me. Regards, Jason On Dec 17, 8:21 pm, Brian Rosner <[EMAIL PROTECTED]> wrote: > I would like to propose splitting django.newforms.models. The reasoning > behind this stems from the work going on in newforms-admin. > django.newforms.models now consists of ModelF

Re: Auto-escaping comitted

On Nov 14, 1:59 pm, Rudolph <[EMAIL PROTECTED]> wrote: > May be I found one corner case. But I'm not sure if this is a bug or a > feature. When using {{ block.super }} is will be escaped, which is > IMHO not the common desired result. One can solve this by using > {{ block.super|safe }}, but perh

Re: full Atom Publishing Format support almost done

On Aug 1, 5:21 pm, James Tauber <[EMAIL PROTECTED]> wrote: > As of r11, the full data model for the Atom Format (RFC 4287) is now > implemented. Great stuff. How easy is it to extend feeds with additional attributes, e.g. for Google Base? Jason --~--~-~--~~~---~--~

Re: Autoescaping: good time?

On Aug 1, 7:31 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > We've seen how bad XSS can be; I think we have an almost moral obligation > here. Agreed; I'm +1 on this proposal for this reason. Genshi [1] seems to do a similar thing: autoescape is on by default. Jason [1] http://genshi.

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

On Jun 15, 4:58 am, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote: > I just checked in a bunch of > changes.http://code.djangoproject.com/changeset/5473 Excellent :-) Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Googl

Re: django-values -> django-policy?

On May 29, 4:56 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > I propose the boring-but-functional "dbsettings" -- settings stored in > the db -- and unless someone can come up with a REALLY good reason not > to use that, I'm going to make a dictatorial call to paint the > bikeshed MY color

Re: django-values -> django-policy?

On May 28, 8:44 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:> > In short, I vote that it be changed to django-policy. I can't change > the URL in Google Code without starting a whole new project (and since > I already have issues in place, I'd rather not do that), but I can > change all the docum

Re: django-values update

On May 18, 5:30 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Indeed; I've been telling people interested in getting stuff into > Django that doing it as a standalone project first is probably the > best idea. I really like the constraints that places on how these > external projects are d

Re: Field.contribute_to_class and contrib fields

On May 15, 11:09 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > It seems to me that keeping such things as attributes of the field > would be desirable since they're related and since doing so would > namespace them. Namespaces are good. :) Agreed. This did cross my mind some time ago actual

Re: Disable admin pagination completely: discussion for ticket #4027

On May 1, 5:20 pm, Marek Kubica <[EMAIL PROTECTED]> wrote: > The current situation is a little bit annoying, with newforms-admin being > nearly ready and oldforms-admin getting unsupported. Yeah, it would be good if newforms-admin could be merged asap. I assume it's just the edit_inline functio

Re: newforms: better table markup

On Apr 2, 8:31 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 4/2/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > On 4/1/07, James Bennett <[EMAIL PROTECTED]> wrote: > > > Anyone have strong opinions against this before I whip up a patch? > > > +1 on adding "headers", -1 on adding

Re: admin-interface: move up/down proposal

Konstantin Khilkevitch wrote: > I believe ticket 13, now in accepted queue, deals with this > functionality: http://code.djangoproject.com/ticket/13 I'm not sure it's exactly the same, as ticket #13 only deals with the ordering of related objects with respect to a particular object. It would be

Re: DecimalField

Jacob Kaplan-Moss wrote: > On 10/26/06 2:49 AM, Christopher Lenz wrote: > > Oh come on, just let Python 2.3 users install the decimal module from > > SF: > > > > > group_id=104148&package_id=130611&release_id=291663> > > > > I'd also suggest keep

Re: DecimalField

Jacob Kaplan-Moss wrote: > On 10/24/06 5:25 PM, Jason Davies wrote: > > I think we should just distribute decimal.py to maintain Python 2.3 > > compatibility. > > I'm +1 on the patch if someone can resolve two things: > > * Is the license for decimal.py compatible

DecimalField

Hi, I am working on an application which deals with monetary values and it *really* needs proper support for decimal, fixed-point (as opposed to floating-point) values. See: http://code.djangoproject.com/ticket/2365 Could someone take a look and get this patch approved? I think we should just

Re: Making URLconfs accept view objects, not just paths to views

+1. Seems more consistent and Pythonic. Cheers, Jason --~--~-~--~~~---~--~~ 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 unsubscri

Re: Opinions requested about validating edit_inline fields

Malcolm Tredinnick wrote: > On Thu, 2006-04-27 at 09:19 -0700, Jason Davies wrote: > > > > > A solution that fits all needs would be to create an extra parameter for > > > these validators (the ones that take field names) that indicates that > > > only fields

Re: Opinions requested about validating edit_inline fields

> A solution that fits all needs would be to create an extra parameter for > these validators (the ones that take field names) that indicates that > only fields for this class should be considered (e.g. only things that > start with model.__name__, in effect) and the dotted bits > ("model.positio

Re: Removing TEMPLATE_FILE_EXTENSION

Adrian Holovaty wrote: > On 4/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > What do you think of the idea (proposed by Luke Plant here: > > http://code.djangoproject.com/ticket/500 ) to remove the > > TEMPLATE_FILE_EXTENSION setting, so that you'd have to specify ".html" > > in each get_t

Re: content types and packages need reworking for magic-removal

Jason Davies wrote: > Luke Plant wrote: > > In addition to your patch, I'd propose changing 'get_model_module()' to > > 'get_model_class()' (also, your patch has a 'get_object', which should > > be just 'get'). > > OK

Re: content types and packages need reworking for magic-removal

Luke Plant wrote: > Jason Davies wrote: > > > 1. Get rid of the 'Package' model - is there any use for it now that > > the magic has gone? > > 2. Replace ContentType's 'package' and 'python_module_name' fields with > > a &#x

Re: content types and packages need reworking for magic-removal

Jason Davies wrote: > I propose: > 1. Get rid of the 'Package' model - is there any use for it now that > the magic has gone? > 2. Replace ContentType's 'package' and 'python_module_name' fields with > a 'model' field. I've

magic-removal: bug reporting

Hi, I've been following the changes in magic-removal and I've noticed various niggly bugs (especially in the latest round of updates) when testing my code. Just simple things, e.g. get_object() should be get() in some of Django's contrib apps. Do you want me to open tickets for them or is that

Re: Typo on magic-removal sql migration script?

On a related note, there's a typo in django.contrib.auth.models in magic-removal - see http://code.djangoproject.com/ticket/1276 Regards, Jason

Re: magic-removal: "Change subclassing syntax"

Joseph Kocherhans wrote: > Is this a good summary of the current thinking on subclassing? > > http://groups.google.com/group/django-developers/browse_frm/thread/ea5e0bf903058fac/9a68ac0d99cb6d7d?q=semantics&rnum=1#9a68ac0d99cb6d7d > > The wiki doesn't say a whole lot about it, although it's proba

Re: DescriptorFields status/Manager API change

Joseph Kocherhans wrote: > At any rate, Managers and ManyToMany/OneToMany attributes do extremely > similar things, and I think they could share an api and maybe even > share most implementation. If managers behaved like object attributes, > this is what I'm worried about: > > MyModel.objects.fi

content types and packages need reworking for magic-removal

Hi, I was just fiddling around trying to get comments working in magic-removal when I came across this in django.contrib.contenttypes.models: def get_model_module(self): "Returns the Python model module for accessing this type of content." return __import__('django.models.%s.

Re: Magic - removal branch .. is the API stable yet?

Robert Wittams wrote: > I personally am not going to be able to work on it any time soon. Sorry. > Anyone else should feel free to give it a stab. I'm keen to get the "semantics of subtyping" stuff done. If you have any implementation hints to help me along that would be really helpful, thanks.

Re: admin reports wrong absolute url

Amit Upadhyay wrote: [snip] > But when I open the objects "change" page in admin, and try to follow "View > on Site" link, it takes me to some http://localhost:6680/r/10/1/, which > 404s. You need to add the following to your urlconf: (r'^r/', include('django.conf.urls.shortcut')), Regards, J

Re: FileField & many to many

Robert Wittams wrote: > The temporary location is a slight issue. My current thinking is : > a temporary location is a directory. It contains two subdirectories, eg > 0 and 1. > We first use the 0 directory. Then after n minutes, we use the 1 > directory. After another n minutes, we use the 0 di

Re: Descriptors for fields?

Robert Wittams wrote: > > You are right, _list is worse than _set. > > > > Would _data be a better solution? > > I don't think so. As a sometimes C/C++ programmer I expect things called > data to be a void*, and come along with a length ;-) I browsed quickly through thesaurus.com. How about: _

Re: Removing the magic

Jacob Kaplan-Moss wrote: > On Dec 8, 2005, at 7:07 PM, Lachlan Cannon wrote: > > Is there a reason we use a DoesNotExist rather than just > > using a > > single ObjectDoesNotExist exception for everything? > > Yes. > > Consider:: > > try: > do_something_that_involves_multiple

Re: Semantics of subtyping

Robert Wittams wrote: [snip] > The other form of subtyping - ( ie is-a relationship) available, is the > one-to-one field. This makes a set of fields an extension to another > object. The way this is generated in django is to add > get_ to each instance of the supertype. A base type > can have a

Re: Name for "choices accessor" methods

Adrian Holovaty wrote: > This would be a great addition, but I feel like the function name > ("get_state_display") could be improved. What could we use instead of > "display"? Perhaps get_fieldname_alt() would be nice?