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.

flo...@gmail.com wrote: >> Actually, they call their package "dojox.dtl". Their documentation >> explains that it implements the Django template language. Yep: http://dojotoolkit.org/book/dojo-book-0-9/part-5-dojox/dojox-dtl > Even still, at a local Python meetup a little over a month ago, >

Re: Perl port of the django template system.

On 17 Dez., 05:46, "flo...@gmail.com" wrote: > > Actually, they call their package "dojox.dtl". Their documentation > > explains that it implements the Django template language. > > Even still, at a local Python meetup a little over a month ago, > someone raised their hand

Re: Perl port of the django template system.

Am 17.12.2008 um 04:11 schrieb Maluku: > It called it that, because it provides a template language like > Django, but if this is a problem I will call it something else. > Apache is a bad example, since many modules that _use_ Apache are also > in the Apache:: Namespace, like Apache::Template

Re: Perl port of the django template system.

> Actually, they call their package "dojox.dtl". Their documentation > explains that it implements the Django template language. Even still, at a local Python meetup a little over a month ago, someone raised their hand and asked a question that went something like this: "I saw that Django

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: Perl port of the django template system.

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 that. That being said, that, amongst other things preceded the existence of the DSF. Alex

Re: Exception emails in django.core.handlers.base

> Put this another way-- how do other people manage high-performance > exception mailing? I'm happily using James Tauber's django-mailer for asynchronous mailing: http://code.google.com/p/django-mailer/ You could for example query the Django app cache if it's installed and fall back to

Re: Exception emails in django.core.handlers.base

On Tue, Dec 16, 2008 at 6:53 PM, Malcolm Tredinnick wrote: ... > You only have to override the handle_uncaught_exception() method -- > that's where the mailing is restricted to. Bah, that's what I get for looking at my pre-1.0 django rev. Sorry for the noise. :-(

Re: Perl port of the django template system.

On 17 Dez., 04:23, Malcolm Tredinnick wrote: > So the problem that you are now mentioning is that you registered the > name first and decided to ask check if there might be a problem only > afterwards. I'm really not trying to be a hard-ass here, but that's not > a

Re: Perl port of the django template system.

I find it interesting that no one has brought up jinja. They did something that follows django's template syntax, and have still built up a community. There is also the ruby version which is called liquid iirc that borrows heavily from django's syntax. Basically, it doesn't need django in

Re: Perl port of the django template system.

On Dec 16, 9:32 pm, Justin Bronn wrote: > > I'm not sure if I work is derived from yours, since I only used the > > documentation (http://docs.djangoproject.com/en/dev/ref/templates/builtins/) > > for my work, but I thougt I would better just ask: > > > Would you please allow

Re: Perl port of the django template system.

On Tue, 2008-12-16 at 21:18 -0600, Arien wrote: > On Tue, Dec 16, 2008 at 8:36 PM, Malcolm Tredinnick > wrote: > > > > All of this is predicated on using the word "Django" in the name, which > > is the bit I have a problem with. > > How is this different from, e.g.,

Re: Perl port of the django template system.

Call it Reinhardt, like the surname of Django :-) On Dec 17, 2008, at 11:18 AM, Arien wrote: > > On Tue, Dec 16, 2008 at 8:36 PM, Malcolm Tredinnick > wrote: >> >> All of this is predicated on using the word "Django" in the name, >> which >> is the bit I have a

Re: Perl port of the django template system.

On Tue, 2008-12-16 at 19:11 -0800, Maluku wrote: > On 17 Dez., 03:36, Malcolm Tredinnick > wrote: > > It's very easy: you just don't call it that. Why does it require > > "change"? > > I have discussed this with the perl naming people here: >

Re: Perl port of the django template system.

On Tue, Dec 16, 2008 at 8:36 PM, Malcolm Tredinnick wrote: > > All of this is predicated on using the word "Django" in the name, which > is the bit I have a problem with. How is this different from, e.g., any of these? http://code.google.com/hosting/search?q=django-

Re: Perl port of the django template system.

On 17 Dez., 03:36, Malcolm Tredinnick wrote: > It's very easy: you just don't call it that. Why does it require > "change"? I have discussed this with the perl naming people here: http://www.nntp.perl.org/group/perl.modules/2008/12/msg63533.html > Choose a different

Re: Custom Fields API Cleanup

On Tue, 2008-12-16 at 12:08 -0600, David Cramer wrote: > I should also note, that these changes, could possibly be carried over > into Model Field's. As IIRC they were suffering from some of the same > problems. Again, specifics are important. Pretty much all existing model fields wrap base

Re: Perl port of the django template system.

Hi, > Changing the namespace is not that easy, sadly. But I can make a > statement that this has nothing to do with the Djangoproject into the > namespace description. That one can be seen everywhere the name is > displayed. Um... I know you registered your namespace with CPAN, but as far as I

Re: Perl port of the django template system.

On 17 Dez., 03:15, Malcolm Tredinnick wrote: > Legalities aside, I'd prefer this wasn't done. It will induce confusion > as there will be some people who think it's associated with the Django > project. Having a description that says it implements the same >

Re: Perl port of the django template system.

On Wed, 2008-12-17 at 01:49 +0100, Marc Lucksch wrote: > I'm currently working on a port of the django template system to perl. > It is going to be called Django::Template, and it is almost finished, > some filters missing, cleaning up the documentation and writing tests. > > My problem is now:

Perl port of the django template system.

I'm currently working on a port of the django template system to perl. It is going to be called Django::Template, and it is almost finished, some filters missing, cleaning up the documentation and writing tests. My problem is now: By calling it Django::Template I'm using your name "Django" to

Re: Exception emails in django.core.handlers.base

On Tue, 2008-12-16 at 16:15 -0600, Jeremy Dunck wrote: > On Tue, Dec 16, 2008 at 3:44 PM, Jacob Kaplan-Moss > wrote: > > > > On Tue, Dec 16, 2008 at 11:56 AM, Jeremy Dunck wrote: > >> Since sending email can block for an arbitrarily long time, I'd

Re: Exception emails in django.core.handlers.base

We simply send them to localhost. Learned the lesson long ago to not spam a normal email account with it :) On Dec 16, 4:15 pm, "Jeremy Dunck" wrote: > On Tue, Dec 16, 2008 at 3:44 PM, Jacob Kaplan-Moss > > > > wrote: > > > On Tue, Dec 16, 2008 at

Re: Exception emails in django.core.handlers.base

On Wed, Dec 17, 2008 at 11:15 AM, Jeremy Dunck wrote: > > Put this another way-- how do other people manage high-performance > exception mailing? Maybe I'm Doing It Wrong. Run postfix on the host server and have Django send errors to localhost. Then postfix queues it and

Re: Default manager

On Tue, Dec 16, 2008 at 11:55 PM, Alex Rades wrote: > On Tue, Dec 16, 2008 at 5:49 PM, James Bennett wrote: >> >> On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato >> wrote: >>> I don't see any downside in this proposal. >> >>

Re: Default manager

On Tue, Dec 16, 2008 at 5:49 PM, James Bennett wrote: > > 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

Re: Exception emails in django.core.handlers.base

On Tue, Dec 16, 2008 at 3:44 PM, Jacob Kaplan-Moss wrote: > > On Tue, Dec 16, 2008 at 11:56 AM, Jeremy Dunck wrote: >> Since sending email can block for an arbitrarily long time, I'd like >> to make it so that when an exception occurs in >>

Re: Exception emails in django.core.handlers.base

On Tue, Dec 16, 2008 at 11:56 AM, Jeremy Dunck wrote: > Since sending email can block for an arbitrarily long time, I'd like > to make it so that when an exception occurs in > django.core.handlers.base, it calls our mail_admins rather than > django's stock mail_admins. > > With

Re: Default manager

+1! > >> So, my proposal is to make the "objects" manager always present and >> accessible, and remove the _default_manager stuff. If you want to >> change the default manager, just override "objects". If you want to >> access the default manager, just access "objects". > > +1 > >

Exception emails in django.core.handlers.base

We've locally implemented an asynchronous mailing system and made it have the same function signatures. So .mail has all the same function names and signatures as django.core.mail. Since sending email can block for an arbitrarily long time, I'd like to make it so that when an exception occurs

Re: Custom Fields API Cleanup

On Tue, Dec 16, 2008 at 2:02 PM, David Cramer wrote: > Could we just use a lazy proxy for the value value? When it's executed, it > could then just call the get_value_from_db method (or whatever). I expect that the lazy approach is what most people would really want, so I'd

Re: Custom Fields API Cleanup

Could we just use a lazy proxy for the value value? When it's executed, it could then just call the get_value_from_db method (or whatever). On Tue, Dec 16, 2008 at 12:37 PM, Marty Alchin wrote: > > On Tue, Dec 16, 2008 at 1:03 PM, Jacob Kaplan-Moss >

Re: Custom Fields API Cleanup

On Tue, Dec 16, 2008 at 1:03 PM, Jacob Kaplan-Moss wrote: > This seems like a good idea to me, and an easy one to implement; I'm > all for it. Are there any backwards-compatibility concerns here? It > doesn't look like it -- we're just talking about adding a new hook

Re: Custom Fields API Cleanup

I should also note, that these changes, could possibly be carried over into Model Field's. As IIRC they were suffering from some of the same problems. On Tue, Dec 16, 2008 at 12:03 PM, Jacob Kaplan-Moss < jacob.kaplanm...@gmail.com> wrote: > > On Tue, Dec 16, 2008 at 9:06 AM, David Cramer

Re: Custom Fields API Cleanup

On Tue, Dec 16, 2008 at 9:06 AM, David Cramer wrote: > The first of which, is the pre_save method. Originally we had been > using get_db_pre_value (which also is passed on to the save method), > and this seems to make a lot more sense than pre_save's > implementation. I'm not

Custom Fields API Cleanup

Recently we've been doing a lot of work with custom fields, and have had a few inconveniences come up. Some minor, some not so much. I'd like to propose a few changes to the API to make it easier to write custom fields, especially those which use custom data structures. The first of which, is

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 Tue, Dec 16, 2008 at 3:44 PM, James Bennett wrote: > > 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"

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: Ticket #5610 - Useful for dumpdata to be able to use a specific model

On 16 Dec 2008, at 10:53, Russell Keith-Magee wrote: >> From an initial inspection, #5610 looks ready for trunk. The feature > is well defined, and the patch now has docs and tests. I'm knee deep > in aggregation code at the moment, but I'll put this on my todo list. Excellent news, thanks

Re: Default manager

> So, my proposal is to make the "objects" manager always present and > accessible, and remove the _default_manager stuff. If you want to > change the default manager, just override "objects". If you want to > access the default manager, just access "objects". +1

Re: upgrade application

On Tue, Dec 16, 2008 at 01:23:15AM -0800, samira wrote: > is anybody know how I can porting my apps from Django 1.0 to 1.0.2? First of all the django-developers list is for development of Django itself, not user questions, you want the django-user list ;) Secondly since 1.0.2 is a bugfix

upgrade application

Hello all is anybody know how I can porting my apps from Django 1.0 to 1.0.2? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to