Re: Ticket #3349 patch review

While I think of it: One thing this patch should address is updating the `contributing` page to mention calling wrap_and_raise whenever you are "catching an exception arising from user-supplied code and then raising a different excepti

Re: Ticket #3349 patch review

On Dec 14, 11:00 pm, ab wrote: > > `wrap_and_raise()` will appear in the traceback, `raise   > > wrap_exception(SomeException())` would be cleaner. > > I like that But you must use the three-argument `raise` statement to supply your own traceback in Python 2.x. You could dispense with the functio

Re: Ticket #3349 patch review

I'm the author of the current patch; I'll just add a bit of background. On Dec 12, 10:18 pm, ab wrote: > > 1. Scope -- the patch generalizes the issue and addresses it > throughout Django. Are people ok with that? Since the problem of raising new exceptions and losing the original one seemed sys

Re: Django releases

On Jun 8, 1:23 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote: > > Where I work we use 0.96 (though I use trunk on my personal projects). >  We use 0.96 because we have up to 12 separate Django projects > rotating through at a time and all at various phases of development. > We don't have the resource

django-updates group broken?

I was looking at django-updates in google groups , and noticed the most recent posting from it was from the 18th of March. It looks like something is broken there... Since updates don't seem to be going through there, can I ask that someone review ticket #3349 ("If an ImportError occurs within a

Re: Calling All Django Developers !

On 10/23/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote: > > Siliconbits skrev: > > We are currently looking for Django developers to join us on a > > freelance basis. Please take this discussion to the django-users list. The django-developers list is for discussion of the development of django its

Re: #2539 - Namespacing template tags and libraries

On 10/23/07, Bruce Kroeze <[EMAIL PROTECTED]> wrote: > Why couldn't both coexist, but be mutually exclusive? > > {% load firstapp.library as mylib %} > {% load thislib thatlib theotherlib %} They could; it would certainly be convenient, and a simple change to implement, but at the expense of a s

Should GenericForeignKey really implement m2m_*? (was Re: GenericRelation DROP generation problems)

On 10/19/07, jdietrich <[EMAIL PROTECTED]> wrote: > > Can someone review the patch I've attached to ticket 3480 and verify > that it is sane? I think that should close out both #3480 and #3549, > and it seems a bit more kosher than the patch on #3549 It looks OK to me, rather along the lines of t

Re: #2539 - Namespacing template tags and libraries

On 10/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Selfishly I would like to be able to do: > {% load firstapp.library as mylib %} > {{ context_var|mylib.myfilter }} I don't think this would play nicely with the existing {% load library1 library2 %} syntax. A. --~--~-~--~

#2539 - Namespacing template tags and libraries

Tick #2539 "Custom tags and filters can be restricted by namespace" was one of the ones I was going to pick up during the django sprint, but someone else beat me to it. However, the other day I noticed that the patch against it was old, and admitted to be incomplete by its author. Since namespac

Re: Discussion of #4131: addslashes, javascript string literals, and (new) escapejs

On 10/17/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > However, there are many strings that can be passed through that > filter and sill will break javascript string literals. Specifically, as you point out, strings that contain "" -- the main point here is to reduce the chances of XSS attack

Re: Request exception handling and exception middleware

On 10/11/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > I think you're completely right about making the exception handler > into a plain old view; the signature (request, exception) seems right, > but I haven't thought it through completely yet. I'd imagine that (request, exc_class, except

Re: Adding a hook for pre-runtime setup (ticket #5685)

On 10/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-10-08 at 09:15 -0400, Benjamin Slavin wrote: > > > > My immediate thought is that we could allow pre-model instantiation > > (as proposed in the ticket) and post-model instantiation hooks > > I don't think we want to do thi

Re: Adding a hook for pre-runtime setup (ticket #5685)

On 10/4/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote: > > I wanted to get a feel for people's opinions on using this approach to > guarantee that certain code is executed before a request is processed > (or the interactive shell is loaded). > > This is necessary (arguably) to setup a listener to

Re: Another urlpatterns proposal (add method column)

On 10/3/07, Simon Litchfield <[EMAIL PROTECTED]> wrote: > > However, using the new-ish urlpattern url() notation would be the go > here. Just bung a new kwarg on url.__init__() with a default of > something like None, ALL or *, that would optionally accept values > like GET, POST, HEAD, etc. Note

Re: repr for lazy translation

On 9/26/07, Wolfram Kriesing <[EMAIL PROTECTED]> wrote: > > I ran into the problem while doing this: > > >>> from django.utils.translation import gettext_lazy as _ > >>> s = _("my string") > >>> s += _("my second string") > Traceback (most recent call last): > File "", line 1, in ? > TypeError:

Re: Ticket #5172 discussion

On 9/25/07, vfoley <[EMAIL PROTECTED]> wrote: > > SmileyChris added a ticket to propose extending the for loop tag to > support numerical looping. I posted a patch that adds such a > capability and includes a few tests. Documentation is still lacking. > Let me know what you think, here are some

Re: #4796 - Needs an expert's eye.

On 9/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Previously, I've wondered about pulling string_concat out of trans_real > and into __init__, since it doesn't depend on the USE_I18N setting at > all. That piece of tidying would avoid some of these problems, too, so I > think I'll do t

Re: #4796 - Needs an expert's eye.

On Sep 22, 2:16 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Thanks, Andrew. That patch looks "intuitively" correct; it's in the > right area of code that I would have expected to find the problem, etc. > I'll have a think about it through today to see if there are any > technical problem

#4796 - Needs an expert's eye.

I was looking into #4796, and submitted a patch that fixes the error -- and I'm fairly sure that it fixes it in the appropriate spot. However, I didn't quite grok the runtime interaction between the __proxy__ objects and the delayed_loader function, so I'd appreciate it if someone else could cast

Re: Maintaining a patched Django (was re: Templates: short comments {##} eats text)

Thanks Michael, Ramiro, and David. I'll read up on the things you've suggested. --~--~-~--~~~---~--~~ 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@goog

Maintaining a patched Django (was re: Templates: short comments {##} eats text)

On Apr 25, 4:46 pm, Michael Radziej <[EMAIL PROTECTED]> wrote: > > My own patch stack currently comprises 22 patches ... and it's still ok and > quite manageable. I'm still up to date with svn. I've been using a patched version of Django for some time, but it's highly inconvenient (I'm using a "v

Re: Logging facility for Django

On Apr 24, 12:23 am, Vinay Sajip <[EMAIL PROTECTED]> wrote: > > > I agree that thread locals would probably be ideal, but it looks like > > threading.local was only introduced in Python 2.4. To stay aligned > > with Django, it should really be 2.3 compatible. > > Fair point - I'd forgotten that th

Re: Django tests failing under Python 2.3

On Jan 29, 4:50 pm, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > On 1/29/07 10:15 AM, Robert Myers wrote: > > > I'm seeing the same amount of errors on python 2.3.4, it appears the @ > > decorator syntax is being used in the modeltests/test-client/views.py. And I was so used to decorators that

Django tests failing under Python 2.3

I'm trying to run all the django tests under Python 2.3.5 (on OS X 10.4.8), and there are lots of failures (see below). My settings file for the test is just: DEBUG = True DATABASE_ENGINE = 'mysql' # 'postgresql', 'mysql', 'sqlite3' or 'ado_mssql'. DATABASE_NAME = 'test'

Patch for #2365 (was Re: Decision on Decimals vs Floats?)

I've added an updated patch for #2365 "models.FloatField should be renamed"[1], against revision 4439 of the trunk. Summary of this patch: * The 'decimal' module from 2.4 is included under django.utils, to ensure Python 2.3 compatibility * db.FloatField handle only floats, and db.DecimalFiel

Re: Decision on Decimals vs Floats?

Michael Radziej wrote: a) Would this introduce an incompatible change of an API? Yes: models.FloatField would always return floats (not Decimals), and introspection of DECIMAL columns would yield DecimalFields (not FloatField). The parameters to FloatField would also change (no precision, et

Decision on Decimals vs Floats?

There are two open tickets regarding decimals vs floats: #200 and #2365. The current situation is untenable for anyone with a need for genuine fixed-point decimal values, as there are too many cases (i.e. at least one :-) where they might be converted to floats, with a loss of accuracy. To summa

Re: Signed Cookies (ticket #3285)

Gulopine wrote: > I've taken the liberty of writing up a contrib middleware to > transparently implement signed cookies in a Django app. It autmatically > signs and validates all cookies on its own, without any other code > needing to know a thing about it. Can you explain the reasons why one wou

Re: Should Django be HTML agnostic?

Rob Hudson wrote: > > 1. Display code should be separate from logic. Ideally, all HTML would > be in template files that one could override if need be in their own > template directory, just like the admin templates. If django.forms did > this, that would be great. The forms framework I wrote out

Re: New newforms code

Mikko Ohtamaa wrote: > > I don't see any drawback for template based widgets expect that running > template engine consumes more CPU cycles. But if that's a problem for > someone, I am willing to buy him/her a new server :) Well, that's a handy coincidence, because it's suddenly become a problem

Re: Proposal: Forms and BoundForms

I'm sorry to say that I missed the thread "Proposal: Forms and BoundForms" last month. I'm very interested in the topic, largely because, having run out of patience with manipulators, I had written code to handle form definition, validation, and rendering that is similar to the proposals describe

Re: Why doesn't models.Manager implement __iter__?

Malcolm Tredinnick wrote: > > The consistent design idea at work here is that a manager provides those > methods that return a Queryset object. That is why we have .all() in the > first place: it provides a way to convert from a manager object to a > Queryset without applying any filters or restri

Why doesn't models.Manager implement __iter__?

Looking at models.Manager, I noticed that for convenience it implements many of the public methods of QuerySet, delegating the calls to its query set. This obviously allows for more convenient behaviour, such as writing MyModel.objects.filter(whatever) instead of MyModel.objects.all().filter(wh

What is the Right Way to handle DECIMAL fields?

In a project I am working on, we need to store monetary values in the database, and we want to avoid floats altogether so that we don't lose precision or have representation errors. The existing FloatField was not suitable for use, because it would sometimes return floats and sometimes decimals, d

Re: New Manipulators and Validation Aware models.

Brantley Harris wrote: > > Here is a sample view using a default CreateManipulator: > def create_poll(request): > try: > m = Poll.CreateManipulator() > poll = m.process(request) > return HttpResponseRedirect('/poll/%d/' % poll.id) > except Form, form: > retu