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

[Jason Davies]

+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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

DecimalField

[Jason Davies]

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 distribute decimal.py to maintain Python 2.3
compatibility.

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: DecimalField

[Jason Davies]

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 with Django's BSD license?

It's definitely GPL-compatible (see
http://www.python.org/doc/Copyright.html) - but I don't think that
necessarily means it's compatible with Django's license.  I am not a
lawyer :-(

> * Are the developers of decimal.py (is that the PSF now?) OK with us
> distributing it?

I'm not sure how easy it is to get in touch with the developers
themselves.

I don't like the option of falling back to floats in Python 2.3 because
it means an application might not produce exactly the same results as
it would using decimals.

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: DecimalField

[Jason Davies]

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 keeping FloatField as it is (i.e. half-broken,
> > depending on DB backend, or fix it to always return floats, but
> > that's break backwards compatibility again), deprecate it, and
> > introduce the new DecimalField. Only the use of DecimalField would
> > require the decimal.py module, same as ImageField requires PIL.
>
> Yeah, this sounds like a very good idea.  Doesn't break existing code, doesn't
> require decimal.py if floats are OK.  I'm +1 on this - any objections?

+1 too.

I think we should fix FloatField to use the correct type in the DB
backend though (and document possible backwards-incompatibilities) -
it's a shame to leave it half-broken before a 1.0 release.

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: admin-interface: move up/down proposal

[Jason Davies]

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 useful to be able to order objects in and of themselves, too.

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: newforms: better table markup

[Jason Davies]

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  (for the same reason we
> > leave  out).
>
> -1 on  for the same reason.
>
> As for "headers," I'm +0.

I'm -0 on the "headers" idea, as it makes the HTML bulkier.  On the
other hand I guess WCAG compliance is a good thing.

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Jason Davies]

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 functionality that we're waiting for,
according to the wiki?  Is anyone working on that or should I work on
it and submit a patch?

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Field.contribute_to_class and contrib fields

[Jason Davies]

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 actually.  It makes more
sense to have model_instance.file_field.url instead of
model_instance.get_file_field_url().

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-values update

[Jason Davies]

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 developed, and it helps stablize the internal
> Django APIs that these projects use.

This project is great, but one little thing that bugs me in general is
that there doesn't seem to be any kind of standard module naming
convention for writing third-party apps like this.  For instance,
django-values expects you to put it in django.contrib.values, which
seems a bit ugly.  I've seen others which expect you to just put the
module in the root namespace (e.g. the django-registration app).

Is there any way around this, or is it just something inherent to
Python?

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Name for "choices accessor" methods

[Jason Davies]

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?

Re: Semantics of subtyping

[Jason Davies]

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 any combination of extensions.
>
>
> I would suggest that the second type of subtyping is a more natural fit
> for python inheritance of model classes.

[snip]

That sounds like a good solution.  Preserving the semantics of Python's
subclassing is important so that things are intuitive and work as
expected.

Would this have any bearing on solving ticket #529 (GenericForeignKey)?

An aside:  will we still break backwards compatibility after milestone
1.0?

Jason

Re: Removing the magic

[Jason Davies]

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_models()
>   except ModelOneDoesNotExist:
>   handle_missing_one()
>   except ModelTwoDoesNotExist:
>   handle_missing_two()
>
> That is, there are times it's good to know what object is missing as
> part of a complex operation.  All DoesNotExist exceptions inherit
> from django.core.exceptions.ObjectDoesNotExist, so you don't have to
> worry about this unless you need it, though.

This is probably obvious, but couldn't the ObjectDoesNotExist class
just have a "model" attribute specifying which model doesn't exist?

--Jase

Re: Descriptors for fields?

[Jason Davies]

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:

_group
_batch
_bundle
_bunch
_clump
_cluster
_crowd
_gaggle (!)
_lot

Hmm, _lot is short and sweet, what do you think?

Or maybe _bag?  I'm not sure if the semantics are quite the same as the
mathematical concept of bag though.

--Jase

Re: FileField & many to many

[Jason Davies]

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 directory again,
> deleting its current contents. This means that any temporary file will
> live for at least n minutes and at most 2n minutes, (as long as requests
> are still being made).
>
> Then, on final save, the file is moved to a more permanent storage area.
> There could be a global temporary area and timeout value, overridable on
> individual file fields.

Just an idea: could the file be temporarily stored in the session
instead?  At least then it won't be sent "over the wire" multiple
times.  Storing it in the session avoids having to introduce yet
another setting variable.  However, this would make FileField dependent
on the sessions stuff, which may not be desirable.

Jason

Re: admin reports wrong absolute url

[Jason Davies]

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,
Jason

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

[Jason Davies]

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.

Jason

content types and packages need reworking for magic-removal

[Jason Davies]

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.%s' % (self.package_id,
self.python_module_name), '', '', [''])

I presume that the contenttypes stuff needs to be reworked a bit for
magic-removal since you can't import from
django.models.. any more.

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.

Thoughts?

Jason

Re: DescriptorFields status/Manager API change

[Jason Davies]

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.filter(creator__exact=5)
> for obj in MyModel.objects:
> print obj

I was under the impression that you'd do something like:

for obj in MyModel.objects.filter(creator__exact=5):
print obj

i.e. .filter() doesn't do anything to the existing MyModel.objects, but
returns a new lazy collection object with extra lookup params.  Thus
you could do:

object_set1 = MyModel.objects.filter(creator__exact=1)
object_set2 = MyModel.objects.filter(creator__exact=2)

Regards,
Jason

Re: magic-removal: "Change subclassing syntax"

[Jason Davies]

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 probably in
> someone's brain ;)

I think that's the best we've got.  Is it worth creating a wiki page?

Jason

Re: Typo on magic-removal sql migration script?

[Jason Davies]

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

magic-removal: bug reporting

[Jason Davies]

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 just wasting time
and tickets, seeing as they're pretty trivial and presumably will be
fixed once the storm has calmed?

Cheers,
Jason

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

[Jason Davies]

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 submitted a patch here: http://code.djangoproject.com/ticket/1280

django.core.management also needs to be updated to use the new content
type model.

Regards,
Jason

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

[Jason Davies]

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 'model' field.
>
> +1 - the 'Package' table now seems to contain two columns with
> identical content.  Just to clarify - the 'model' field will contain
> the fully qualified python name of the class, right?

Correct.

> 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.  I've just noticed that the permissions stuff in
django.contrib.auth depends on packages at the moment.  Do we want to
change the 'Permission' model so that it has a ForeignKey to
ContentType instead?

Cheers,
Jason

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

[Jason Davies]

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.  I've just noticed that the permissions stuff in
> django.contrib.auth depends on packages at the moment.  Do we want to
> change the 'Permission' model so that it has a ForeignKey to
> ContentType instead?

I've attached a new patch to http://code.djangoproject.com/ticket/1280
which updates django.contrib.auth and django.core.management as well.

Jason

Re: Removing TEMPLATE_FILE_EXTENSION

[Jason Davies]

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_template() call?
>
> OK, I've committed this change to magic-removal:
>
> http://code.djangoproject.com/changeset/2700
>
> I've documented necessary changes here:
>
> http://code.djangoproject.com/wiki/RemovingTheMagic#Includetemplateextensionexplicitly
>
> Please poke around and file a ticket if I've missed anything.

I think generic views still need to be updated, see ticket #1643 .

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Opinions requested about validating edit_inline fields

[Jason Davies]

> 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.position.") should be stripped before comparison. But that
> removes the ability to differentiate between client.0... and
> client.1...; not sure if that is a real problem or not at the moment.
> Fixing this latter case is not completely trivial, because validating
> form input does not know about models or edit_inlines or anything:
> everything is just a bunch of strings at that point.

How about passing an optional name_prefix parameter to these
validators, which would allow them to look up things like
all_data[name_prefix + other_field_name]?  name_prefix would be
something like 'foo.0.' or 'foo.1.' when edit_inline is used.

Regards,
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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Opinions requested about validating edit_inline fields

[Jason Davies]

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 for this class should be considered (e.g. only things that
> > > start with model.__name__, in effect) and the dotted bits
> > > ("model.position.") should be stripped before comparison. But that
> > > removes the ability to differentiate between client.0... and
> > > client.1...; not sure if that is a real problem or not at the moment.
> > > Fixing this latter case is not completely trivial, because validating
> > > form input does not know about models or edit_inlines or anything:
> > > everything is just a bunch of strings at that point.
> >
> > How about passing an optional name_prefix parameter to these
> > validators, which would allow them to look up things like
> > all_data[name_prefix + other_field_name]?  name_prefix would be
> > something like 'foo.0.' or 'foo.1.' when edit_inline is used.
>
> I do not think it makes any difference whether you do it in the thing
> calling the validator or in the validator itself. The thing calling the
> validator still doesn't know anything about models or any semantics, it
> just works with strings. So all you can do is look at the string and say
> "hey, this is a string, followed by a dot followed by a digit followed
> by a dot. I should strip it". Might as well put that inside the
> validator if it is wanted.
>
> What you can't do is determine "now I am processing the model with
> edit_inline" set, because it is only working with strings.
>
> So I think your solution is exactly the same as the one I suggest above,
> just triggered from a different place. It seems harder to set up the
> calling section (your method) to pass in the optional name parameter,
> too, rather than setting the option on the validator. But maybe I'm
> missing something.

I'm not sure your solution will work properly, since validators still
need some way of knowing what "position" is in "model.position.field"
when they're called.  Currently they are only passed (field_data,
all_data) as parameters.  How about passing a field_name parameter too,
then the validator can mess around with stripping dots and so on if
needed?

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

[Jason Davies]

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
ModelChoiceIterator.  See ticket #7475 [1] for a patch and more
details.

I'm not sure there's good way to add a regression test for something
like this, any comments would be appreciated.

Cheers,

Jason

[1]: http://code.djangoproject.com/ticket/7475
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Jason Davies]

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 database.
>
> Would there be any way to analyze which constraints could be affected by
> the SQL executed while checks were disabled, so automated checks could
> be limited to those?

I'd be in favour of doing something like this, even if it was slow.
After all, slow is better than it not working at all!

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Jason Davies]

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
condition again if cache_choices is True.  The other options I can see
are:

1. Utilise Django's cache framework to implement caching of choices
(would need to decide on which cache key to use, and thread-safety
would depend on the cache backend).
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 be no performance impact.
3. Drop support for cache_choices altogether, as it can be easily
implemented (e.g. using the cache framework) if really necessary.

I feel that #2 is the best choice, what do other people think?

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Jason Davies]

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 be no performance impact.

I found a way to cache the choices without having to use any locks
[1].

Cheers,

Jason

[1]: http://code.djangoproject.com/attachment/ticket/7475/models.3.py.diff
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Using RequestContext by default in default 500 handler

[Jason Davies]

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 using
RequestContext first and then falls back to using Context if that
fails.

I opened ticket #6377 [1] a while ago, but it was closed with a
comment that the default error handler was written in such a way as to
lessen that chance of any new exceptions being raised.  I fully
understand this reasoning, but it seems to me that my patch does fall
back to using the "plain" Context if any new exceptions are raised,
thus alleviating the problem mentioned in the comment.  Is there
something I've missed here?

Any thoughts would be appreciated,

Jason

[1] http://code.djangoproject.com/ticket/6377
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Updated patch for ticket #6213

[Jason Davies]

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 #6167.

Could someone review the patch please?

Thank you,

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Updated patch for ticket #6213

[Jason Davies]

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".  The
> patch now contains unit tests demonstrating how it fixes lack of
> expected behaviour when FlatpageFallbackMiddleware or similar is
> used.  The patch also fixes #6167.
>
> Could someone review the patch please?
>
> Thank you,
>
> 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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANNOUNCE: Django 1.0 released

[Jason Davies]

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 developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-values -> django-policy?

[Jason Davies]

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 documentation and add a note explaining the
> discrepancy.

Sounds a bit too generic for me.  I'd prefer something like "dynamic
settings".

Maybe you should just name it after an animal or a plant ;-)

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: django-values -> django-policy?

[Jason Davies]

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.

+1.

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Jason Davies]

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 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Autoescaping: good time?

[Jason Davies]

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.edgewall.org/wiki/GenshiFaq#HowcanIincludeliteralXMLintemplateoutput


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: full Atom Publishing Format support almost done

[Jason Davies]

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


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Auto-escaping comitted

[Jason Davies]

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 perhaps it's even more template-developer
> friendly to not escape {{ block.super }} by default.

I discovered this problem too.  I'd expect {{ block.super }} not to be
escaped by default; can it be safely marked as safe though?

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 unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Splitting django.newforms.models

[Jason Davies]

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 ModelForm, the model choice
> fields and the model related formset code. I am working on a patch that
> adds declarative style formsets which increases the code related to
> model formsets. Its just becoming a bare to work with sometimes. I
> wanted to see how everyone felt if it were to be split up like so:
>
> django
> |
> - newforms
>   |
>   - models
> |
> - __init__.py
> - fields.py
> - forms.py
>
> That would be how it would layout in trunk so then newforms-admin would
> add a formsets.py to the mix and nicely cleaning everything up. I am
> more than happy to open a ticket and write up a patch if everyone is in
> favor of this small clean up.
>
> --
> Brian Rosnerhttp://oebfare.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---