Adrian wrote:
> Anybody care to tackle the separation of Django templates? The main
> thing is decoupling it from django.core.settings (and, hence,
> DJANGO_SETTINGS_MODULE), of which I'm not sure what the best
> approach would be.
a simple solution would be to use lazy loading of the settings
m
>a simple solution would be to use lazy loading of the settings
>module in django.template, change all template code to access
>the settings via django.template.settings, and let an external
>user configure the template package *before* loading the first
>template:
Should be doable since now sett
OK
I've ran Django with psyco and hit it with 50 requests, here are the
results:
without psyco:
265822 function calls (207471 primitive calls) in 3.547 CPU
seconds
with psyco:
66865 function calls (63420 primitive calls) in 1.457 CPU
seconds
So basically - if you want a quick D
On Feb 3, 2006, at 3:28 AM, [EMAIL PROTECTED] wrote:
a simple solution would be to use lazy loading of the settings
module in django.template, change all template code to access
the settings via django.template.settings, and let an external
user configure the template package *before* loading th
On Feb 3, 2006, at 6:46 AM, Wojtek/brandlay.com wrote:
without psyco:
265822 function calls (207471 primitive calls) in 3.547 CPU
seconds
with psyco:
66865 function calls (63420 primitive calls) in 1.457 CPU
seconds
So basically - if you want a quick Django - use psyco :)
Wo
I enabled it in the runserver function of management.py for the tests,
since I've done them on the builtin server.
I just finished testing it with FCGI and it gives a 2x speed gain after
enabling it in the WSGIHandler. I posted a patch with it
http://code.djangoproject.com/ticket/1323
Hopefuly
On 2/3/06, Wojtek/brandlay.com <[EMAIL PROTECTED]> wrote:
> I just finished testing it with FCGI and it gives a 2x speed gain after
> enabling it in the WSGIHandler. I posted a patch with it
> http://code.djangoproject.com/ticket/1323
>
> Hopefuly someone will add it to the trunk :) I'm going to
On Feb 3, 2006, at 9:20 AM, Adrian Holovaty wrote:
Thanks for this patch. I've added it to trunk. My only concern is that
the Psyco Web page says "[t]here are some subtle semantic differences
(i.e. bugs) with the way Python works; they should not be apparent in
most programs." Perhaps some of Dj
I've created a ticket for this task:
http://code.djangoproject.com/ticket/1321
Hi,I was going through magic removal wiki page, and encountered this, I think there is still some magic left in the Custom managers, and multiple managers section. I have a following objections:
finding the default manager based on the order in which they are definedmanager instance magically conta
Ok I gave psyco a try, and it works OK speeding things up 2 times as
benchmarked. My OS is 32bit, running on 64bit machines so probably
that's why I didn't run into the bug you're describing Jacob.
I had issues with the whole thing hanging on one machine, either
because of the SVN FLUP version o
Hi Adrian,I'm new to Django - but I have written a metaclass based ORM before and I *have* seen psyco do weird things - sometimes causing a spontaneous crash. Maybe include a disclaimer that "your mileage may vary" if you turn on psyco.
vicOn 2/3/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On
It is currently very difficult to have models anywhere except models.py.
The reason is to do with the way that the ModelBase metaclass (1) works
out the app_label, (2) adds the '_MODEL' attributes to the module
containing the model classes. Importing the model classes into
models.py doesn't
I also suppose you could do something like, in the base class:
_name = None
_password = None
And then in the __init__ function the end user could set _name and
_password, but the get_* functions just seems simpler and more
Django-styled.
I was looking at the Removing The Magic wiki page, and it seems you
have no plan to remove the magic from the auth module. This came as
quite a disappointment to me. Many things in the auth module are
magical, and the auth model makes many assumptions.
The auth model can still be easy and fun to
Also I haven't given any thought to the inner Admin class. I'll leave
that as an exercise to the reader, simply because I don't even really
agree with how the inner Admin class is setup.
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
> The auth model can still be easy and fun to use, and most importantly
> provide a simple means of a login system.
>
> Currently the auth model does the following:
>- Assume that we want to use columns such as "First Name" and "Last
>
Okay Adrian, I will write a patch. Should I upload it to my site and
send it through here or the bug tracker?
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
> Okay Adrian, I will write a patch. Should I upload it to my site and
> send it through here or the bug tracker?
Use the bug tracker. Here's all you need to know:
http://www.djangoproject.com/documentation/contributing/#submitting-patch
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
>
> I was looking at the Removing The Magic wiki page, and it seems you
> have no plan to remove the magic from the auth module. This came as
> quite a disappointment to me. Many things in the auth module are
> magical, and the auth model
# I think this would be cleaner if there were an authentication
# utility (just a class probably) that you could switch by changing a
# setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'
I think it's also worth noting that this won't work if you ever want
to try a sequence of au
On 2/3/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
>
> # I think this would be cleaner if there were an authentication
> # utility (just a class probably) that you could switch by changing a
> # setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'
>
> I think it's also worth
I'm not able to write the patch because Django is placing too many
restrictions on what I can do as far as this.
What's on the board for the pycon sprint?
Auth back ends?
Components?
More DBs supported?
I'm not going to be familiar with all of django's code, so having some
place to focus on would be good...
On Friday 03 February 2006 22:18, Luke Plant wrote:
> It is currently very difficult to have models anywhere except
> models.py. The reason is to do with the way that the ModelBase
> metaclass (1) works out the app_label, (2) adds the '_MODEL'
> attributes to the module containing the model classes
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote:
>
> I'm not able to write the patch because Django is placing too many
> restrictions on what I can do as far as this.
Err, simply because some people are raising concerns about the
proposed implementation? Or do you mean something to do
Writing a patch just requires too much effort. I give up and I'm
reluctantly trying to hack this together now. And it's not even fun
like the website says it is. :-(
If you are interested the problem happened when I looked at the
formfields file. I don't know how I would make that custom auth class
friendly...
And also the Admin and Meta classes.
Okay so I can probably easily do it but I'm too lazy. Also I need to
get the auth module to use our subclass of the User class and not the
original class. I'm honestly not sure how I should do this in such a
way it conforms to Django standard.
...Horrible api example deleted...
> Cramming everything in a class will always force us to do some meta
> programming.
This has no meaning as far as I can tell. Are you seriously suggesting
that we shouldn't even use metaclasses?
>Devoting a module and spreading things give better flexibility.
Joseph Kocherhans wrote:
On 2/3/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
# I think this would be cleaner if there were an authentication
# utility (just a class probably) that you could switch by changing a
# setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'
I think
On 2/4/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
...Horrible api example deleted...Lets see. > Cramming everything in a class will always force us to do some meta
> programming.This has no meaning as far as I can tell. Are you seriously suggestingthat we shouldn't even use metaclasses? Well I a
33 matches
Mail list logo
