Re: URL dispatcher slow?

[Florian Apolloner]

Hi,

I won't answer your rheotircal questions ;)

On Thursday, October 11, 2012 8:02:19 AM UTC+2, Yo-Yo Ma wrote:
>
> BUT... Django is NOT that fast. 
>

We do know that (you know that and probably everyone else too) and I 
already said in my post that Django isn't the fastest framework out there.

The list goes on. What is the harm in discussing the weak points of Django? 
> Performance is probably the only major weak point in Django right now 
> (aside from the lack of schema migration in core, which is coming soon 
> anyway). 
>

There is no harm in discussing weak points in Django, we do it all the 
time. I just don't think that copy pasting a link (and that more than once) 
to a benchmark which is (imo) just there as a marketing strategy for 
another framework (note: I am not saying the benchmarks are a fake, I am 
just saying they probably aren't representive) adds real value to the 
discussion.

I have no solution or patches in my pocket, but I can say with absolute 
> certainty that performance will never, ever get better when discourse is in 
> a monologue format. 
>

I agree to some extend, but I think you shouldn't forget that many core 
devs use Django on somewhat large-scale deployments (read: definetely way 
over a blog) and performance issues are fixed as needed. But yes, as you 
said stuff like templates are probably slower than they should be :/

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/iVOJwI_v07kJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Russell Keith-Magee]

On Thu, Oct 11, 2012 at 2:02 PM, Yo-Yo Ma  wrote:
> Why does every conversation about Django's performance met with "GTFO we 
> don't care"? (that was a rhetorical question :).

Ok - If this is where the conversation is starting, it's going to go
downhill *very* fast.

Consider this a warning to *everyone* on this thread: we expect *all*
participants to maintain a civil and professional tone. Anyone
engaging in ad hominem attacks, straw man arguments, or any other sort
of offensive behaviour will be banned from posting. I'm not directing
this at anyone in particular - yet. But this is the second thread in a
week that has started down this path, and I want to make the rules
*absolutely* clear before anything gets out of control.

Back to the topic at hand:

We are interested in any concrete proposal that serves to improve
Django's performance.

However, we have no interest in optimisations for the sake of beating
some arbitrary benchmark score.

In addition, any claim that Django is "too slow" for practical
purposes is *demonstrably* false. There are *thousands* of sites in
production that are quite happily using Django. Many of them are
*very* large sites, serving *enormous* amounts of traffic. So, let's
dispense with the hyperbole that implies Django performance is so bad
it is only suitable for toy sites.

That said - could Django be faster? Sure. *Anything* can be improved.

So, if you've got a suggestion, make it. If you think URL resolving is
the source of the problem, propose a way to improve the speed of URL
resolvers. If you think the template language is the problem, propose
a fix.

And don't just say "Why are Django's URL resolvers slow?". Do some
profiling, and come back with an analysis of where the time is being
spent and/or wasted. Come up with a proposal for how Django's URL
resolvers could be made pluggable so that you can swap in a faster
resolver as an option.

We'll happily discuss concrete suggestions. We won't engage in fishing
expeditions.

Yours,
Russ Magee %-)

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Tom Evans]

On Thu, Oct 11, 2012 at 7:02 AM, Yo-Yo Ma  wrote:
> Why does every conversation about Django's performance met with "GTFO we 
> don't care"? (that was a rhetorical question :). I'd venture to guess that 
> most "It's fast enough for me!" responses are predicated on experiences that 
> can be likened to personal blog development, rather than large scale, 10+ 
> server deployments (e.g., Disqus, et al).

At $JOB, we used to write our websites in C++. No, really, we used to
write all our web apps as part of custom apache modules that used our
own C++ framework. If I compared our C++ url routing code against any
of those python stacks tested, it would absolutely murder them. Yet we
don't write new websites in C++ - why?

The expensive parts of a website are not routing requests, it is DB
queries and waiting to write responses to clients. When you look at it
like that, the speed of "grunt" parts of your framework is simply not
relevant. Django's template system is considerably faster than our
XSLT templates we used in C++ (that doesn't paint XSLT in a good
light).

So, the benchmarks are interesting. They tell us which stacks are
fully featured, and which stacks are very lightweight. Apart from
that, they don't tell us much at all - is Django's template engine
slow, or is it about right for the work it does? This benchmark
doesn't tell us that, it only says it is slower than a bare bones
template engine, which is unsurprising, and shouldn't be a cause for
concern.

Cheers

Tom

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Schema Alteration update

[Luke Plant]

On 28/09/12 08:41, Andrew Godwin wrote:
> Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps
> not loudly enough - Jacob and I had a talk at DjangoCon EU where he said
> he wanted it all in core, and I tend to agree.
> 
> Preston has had a look at what I'm doing/planning with AppCache and
> apparently it'll be compatable with what's in app-loading with a little
> work, which is reassuring.
> 
> Only remaining question is whether migration-runner (the smarts) should
> be in contrib or core. I know Alex believes core; I'm split, seeing as
> some people will want to turn it off (so contrib), but it overrides core
> commands like syncdb (so core would be cleaner).

I'm very happy with South being in core/contrib, but I am aware of other
people who use different solutions. It would be nice if we didn't make
life hard for them. I don't know what that means in practice, but if we
got feedback from the developers of those other solutions it would be
good. We might need something like a 'syncdb --ignore-migrations' option.

Luke


-- 
"Because Your lovingkindness is better than life,
 My lips shall praise You."  (Ps 63:3)

Luke Plant || http://lukeplant.me.uk/

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Moonlight]

Well I am not that good to get it fixed it django... it quite easy get 
lost there. But I definitely would appreciate if someone from core team I 
guess or in the community finally have a look there...

That said, if you really think Django's urlresolver is to slow, go ahead, 
> profile it and improve it, we certainly won't say no to speed improvements…
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/CZfjypvjpPQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django 1.5: AUTH_USER_MODEL and GeoManager

[Max]

Hi there,
this is my first post here; hope I'm posting to the right group.
I'm currently working on getting to run an 1.4-application (using a profile 
model) on 1.5dev, using the the new (eagerly awaited by me) 
custom user model.
I used django.contrib.gis.db.GeoManager with my former profile-Model and so 
I wanted to use it with my new custom user model, too.
The following exception was thrown:

" 'GeoManager' object has no attribute 'get_by_natural_key' "

Hacking contrib/gis/db/models/manager.py and making GeoManager subclass 
'django.contrib.auth.models.UserManager' 

instead of 'Manager' solved it for the moment.

Maybe this is something that hasn't been thought of yet.

I felt like I should post this.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/BAKqg0AKWjkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Moonlight]

>
> So, the benchmarks are interesting. They tell us which stacks are 
> fully featured, and which stacks are very lightweight. Apart from 
> that, they don't tell us much at all - is Django's template engine 
> slow, or is it about right for the work it does? This benchmark 
> doesn't tell us that, it only says it is slower than a bare bones 
> template engine, which is unsurprising, and shouldn't be a cause for 
> concern.
>
 
It is sort of no sense. Django is fully featured and we do not care... some 
other are fast because they are lightweight... tell me which 'full 
featured' feature prevents it from become better. I guess for the #1 
framework it is important to be leader... hmm... not sure what you mean by 
'right for the work it does'... who needs a template that doesn't do what 
you need?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/YAcwku7WouYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Fw: URL dispatcher slow?

[Kkk Kkk]

somehow it went to wrong address... sorry, here it is.

- Forwarded Message -


>This is why I disagree with your conjecture that because Django is
>slower than another framework, therefore Django is slow. That is not
>what is shown, only that the other frameworks do certain things
> faster.

I think we have the same standpoint of view here. May be it is faster somewhere 
else... but where? If it is slower here and there... it is probaly just slow, 
isn't it? May be the word 'slow' is not correct... if the framework does more 
for me in URL dispatch I want to know what that more means... I know it can do 
reverse url but that feature is not used in url dispatch.

>Open source is wonderful, because you are allowed the choice of
>framework. You can choose full featured, and accept that those
>features will cost time, or you can choose lightweight, and not use
>those features. There is no magical mid-way point where you get all
>the features and all the speed.

Agreed. We are free to talk about this and that is good. It would be better if 
someone also listen. If the difference between lightweight and full featured 
impacts performance that much I want to see which features cause that. Let 
itemize the list. Honesty I tried... but just can not related them to the facts 
faced.




 From: Tom Evans 
To: Moonlight  
Sent: Thursday, October 11, 2012 3:46 PM
Subject: Re: URL dispatcher slow?
 
On Thu, Oct 11, 2012 at 1:07 PM, Moonlight  wrote:
>> So, the benchmarks are interesting. They tell us which stacks are
>> fully featured, and which stacks are very lightweight. Apart from
>> that, they don't tell us much at all - is Django's template engine
>> slow, or is it about right for the work it does? This benchmark
>> doesn't tell us that, it only says it is slower than a bare bones
>> template engine, which is unsurprising, and shouldn't be a cause for
>> concern.
>
>
> It is sort of no sense. Django is fully featured and we do not care... some
> other are fast because they are lightweight... tell me which 'full
 featured'
> feature prevents it from become better. I guess for the #1 framework it is
> important to be leader... hmm... not sure what you mean by 'right for the
> work it does'... who needs a template that doesn't do what you need?

You are absolutely right - personally, I do not care one iota how fast
Django routes requests. I know that it does it fast enough, and that
improving the speed of that tiny subsection of code is not going to
improve the performance of my web application. This part of code makes
up a disproportionally small part of the request cycle, even if it was
twice as fast, the overall improvement would be negligible.

This is why I disagree with your conjecture that because Django is
slower than another framework, therefore Django is slow. That is not
what is shown, only that the other frameworks do certain things
faster.

>From your previous post, talking about
 urlresolver:

> I definitely would appreciate if someone from core team I guess or in the 
> community finally have a look there

Django's url resolver _is_ fast. It does a lot more work than the
other frameworks under test, which is why it is subjectively slower
than them in that test, but that is not relevant. It could be made
faster, if it stopped doing the useful features that we rely on to
build our projects.

Open source is wonderful, because you are allowed the choice of
framework. You can choose full featured, and accept that those
features will cost time, or you can choose lightweight, and not use
those features. There is no magical mid-way point where you get all
the features and all the speed.

Cheers

Tom

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Yo-Yo Ma]

I only now realized that this thread had started in a bit of a trolling 
fashion, and that there was a similar thread this week. That helps to explain 
the slightly more defensive stance.

Django can survive (and thrive) just fine in its current, reasonably performant 
state, but performance should have a priority, rather than being in a sort of 
"its fine as-is" stasis. 

Benchmarks like the ones posted aren't that helpful, but it doesn't change the 
fact that there tends to be an anti-performance sentiment in this group. When 
you look at the latest Python 3.3.x release, you see that there are many 
performance improvements that are clearly not due to incidental changes. I'm 
merely suggesting that an initiative to better the performance of Django, 
perhaps by benchmarking to find some of the weakest points, determining the 
lowest hanging fruit, and creating tickets in trac for them. I would love to 
help optimize any given part of Django and submit a patch, but not if I'm 
afraid that it will never be applied and/or the ticket will be marked as "works 
for me", etc. Help give us who care about performance the most a real chance to 
make some improvements. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bxfyOKgoRogJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Daniel Sokolowski]

I absolutely agree with: if we were looking for speed we wouldn't use python at 
all (period).

From: Florian Apolloner 
Sent: Wednesday, October 10, 2012 6:29 PM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?

Oh cmon,

please stop playing a socket puppet for the wheezy.web author. A web framework 
consists of more than just a win in speed (an the author of wheezy.web can 
argue whatever he wants that "basic" stuff stuff should be fast) -- if we were 
looking for speed we wouldn't use python at all (period). The goal is to be 
fast enough and be able to scale out horizontally, everything else is not 
really interesting in the case of web development. While I won't deny that 
Django isn't the fastest framework out there it certainly gets it's job done 
more than good enough and that's all it matters. I don't know what your goal 
is, but please stop posting such meaningless comparisons on django-dev…

That said, if you really think Django's urlresolver is to slow, go ahead, 
profile it and improve it, we certainly won't say no to speed improvements…

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/DgNcKfL2AeUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Daniel Sokolowski
http://webdesign.danols.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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Tom Evans]

On Wed, Oct 10, 2012 at 7:52 AM, Moonlight  wrote:
> Here is an article comparing various URL dispatchers:
>
> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>
> What cause django URL dispatcher that much... slow?
>

Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.

In a normal django application, you do not start from fresh on each
request. This explains why the performance degradation from
"static[0]" to "static[-1] " - which is the difference between testing
the first url in the urlconf and the last url in the urlconf - is so
pathological, each time it is run Django is recompiling each and every
URL regexp in the urlconf (as well as _all_ other work django does at
server start).

This is testing something, but it is not testing django as a web
application, or as Django is intended to be run.

Cheers

Tom

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Alex Gaynor]

On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:

>   I absolutely agree with: if we were looking for speed we wouldn't use
> python at all (period).
>
>
Speak for yourself.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Daniel Sokolowski]

Was that necessary?  I am tuning out of this conversion, it is becoming 
hostile. 
From: Alex Gaynor 
Sent: Thursday, October 11, 2012 10:01 AM
To: django-developers@googlegroups.com 
Subject: Re: URL dispatcher slow?




On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski 
 wrote:

  I absolutely agree with: if we were looking for speed we wouldn't use python 
at all (period).


Speak for yourself.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to say 
it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Michael]

This conversation is getting nasty. Django's URL dispatcher is what it is.
If you can get the flexibility that the current URL dispatcher provides
while making it faster, I imagine everyone on this thread would be
impressed.

There is no reason to use Django's URL dispatcher. It is quite easy to map
a WSGI path to the view functions. Heck, you can even write your own URL
dispatcher and let us all see your method. Maybe it will get traction.

I have not seen performance bottlenecks on templates or URL dispatchers. My
systems tend to bail due to the database or IO first. So benchmarks are
great and something to keep an eye on while adding new features or making
changes, but I am not going to worry about the abstract performance of URL
Dispatchers until it is clear that it accounts for a clear problem in the
request/response cycle.

Other than that we are seeing problems that are not actually there and
nothing will ever get done.


On Thu, Oct 11, 2012 at 10:01 AM, Alex Gaynor  wrote:

>
>
> On Thu, Oct 11, 2012 at 6:52 AM, Daniel Sokolowski <
> daniel.sokolow...@klinsight.com> wrote:
>
>>   I absolutely agree with: if we were looking for speed we wouldn't use
>> python at all (period).
>>
>>
> Speak for yourself.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>
>  --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Ole Laursen]

On Tuesday, October 9, 2012 7:15:55 PM UTC+2, ptone wrote:
>
> Earlier discussion
>
> https://groups.google.com/forum/?fromgroups=#!topic/django-developers/Saa5nbzqQ2Q
>

This was the thread I referred to. If was from 2006 and ended up being 
about something else.
 

> tickets:
>
https://code.djangoproject.com/ticket/17546
>

Closed as dupe with no further analysis.
 

> https://code.djangoproject.com/ticket/2659
>

This is about a different API which is a bit more cumbersome. And it was 
closed 6 years ago with a - "this could be feature creep".
 

> https://code.djangoproject.com/ticket/11352
>

This is a different proposal.


Just to expand slightly on my proposal - I don't actually want to get 
anything else than None out of get. I just want something that makes 
intuitive sense to a Python programmer and saves me from the annoying 
try-except pattern or the related:

objs = SomeClass.objects.filter(slug="xyz")
obj = None
if objs:
obj = objs[0]

which I often end up shortening as

obj = SomeClass.objects.filter(slug="xyz")
if obj:
obj = obj[0]

You can't get a zero or one objects out of the ORM elegantly, something I 
find I have to do relatively often in some code bases. I don't consider 
try-except intuitive for a situation where the exception case isn't 
exceptional.

default=None makes sense when you are used to dicts, .first() or 
.get_or_none() or .getnone() or .single() would be fine too.


Ole

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/r8vZ2A9tIkgJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Aymeric Augustin]

2012/10/11 Tom Evans 

> Now that I've looked in detail at the test, it is because the test is
> nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
> application. Each fresh application has to compile each URL in the
> urlconf before using it. It then destroys the application, and starts
> another one up.
>

Hi Tom,

The performance gap was really huge, roughly two orders of magnitude.
I had a gut feeling that the implementation of the URL resolver couldn't
explain it fully. This makes much more sense.

So, thank you for checking the benchmark's source code!

(I have to admit that I was too lazy and didn't care enough to do it
myself.)

-- 
Aymeric.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.5: AUTH_USER_MODEL and GeoManager

[Luke Plant]

On 11/10/12 08:51, Max wrote:
> Hi there,
> this is my first post here; hope I'm posting to the right group.
> I'm currently working on getting to run an 1.4-application (using a
> profile model) on 1.5dev, using the the new (eagerly awaited by me) 
> custom user model.
> I used django.contrib.gis.db.GeoManager with my former profile-Model and
> so I wanted to use it with my new custom user model, too.
> The following exception was thrown:
> 
> " 'GeoManager' object has no attribute 'get_by_natural_key' "
> 
> Hacking contrib/gis/db/models/manager.py and making GeoManager subclass 
> 'django.contrib.auth.models.UserManager' 
> 
> instead of 'Manager' solved it for the moment.
> 
> Maybe this is something that hasn't been thought of yet.
> 
> I felt like I should post this.

If you could create a ticket, that will ensure this is not forgotten. It
sounds like it should be a release blocker.

Luke


-- 
"Because Your lovingkindness is better than life,
 My lips shall praise You."  (Ps 63:3)

Luke Plant || http://lukeplant.me.uk/

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Marco Paolini]

On 11/10/2012 15:53, Tom Evans wrote:

On Wed, Oct 10, 2012 at 7:52 AM, Moonlight  wrote:

Here is an article comparing various URL dispatchers:

http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html

What cause django URL dispatcher that much... slow?



Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.

no, the wsgi handler is instatiated only once and outside the timeit call


--
markopaol...@gmail.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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[ptone]

On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>
>
> That said - could Django be faster? Sure. *Anything* can be improved. 
>
> So, if you've got a suggestion, make it. If you think URL resolving is 
> the source of the problem, propose a way to improve the speed of URL 
> resolvers. If you think the template language is the problem, propose 
> a fix. 
>

To do my part to increase the signal:noise.

I'll point out that just as writing a failing test is a great way to 
augment a bug report - contributing or improving a benchmark for:

https://github.com/jacobian/djangobench

would be a good way to contribute to a discussion around a particular 
performance improvement you're interested in seeing happen.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/kI7jNl7gYwEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Marijonas Petrauskas]

You can use:

obj = next(iter(SomeModel.objects.filter(foo='bar')), None)

The 'iter' part is not particularly elegant, but it's the only one-liner
known to me.


-- Marijonas

On Thu, Oct 11, 2012 at 3:45 PM, Ole Laursen  wrote:

> On Tuesday, October 9, 2012 7:15:55 PM UTC+2, ptone wrote:
>>
>> Earlier discussion
>> https://groups.google.com/**forum/?fromgroups=#!topic/**
>> django-developers/Saa5nbzqQ2Q
>>
>
> This was the thread I referred to. If was from 2006 and ended up being
> about something else.
>
>
>> tickets:
>>
> https://code.djangoproject.**com/ticket/17546
>>
>
> Closed as dupe with no further analysis.
>
>
>> https://code.djangoproject.**com/ticket/2659
>>
>
> This is about a different API which is a bit more cumbersome. And it was
> closed 6 years ago with a - "this could be feature creep".
>
>
>> https://code.djangoproject.**com/ticket/11352
>>
>
> This is a different proposal.
>
>
> Just to expand slightly on my proposal - I don't actually want to get
> anything else than None out of get. I just want something that makes
> intuitive sense to a Python programmer and saves me from the annoying
> try-except pattern or the related:
>
> objs = SomeClass.objects.filter(slug="xyz")
> obj = None
> if objs:
> obj = objs[0]
>
> which I often end up shortening as
>
> obj = SomeClass.objects.filter(slug="xyz")
> if obj:
> obj = obj[0]
>
> You can't get a zero or one objects out of the ORM elegantly, something I
> find I have to do relatively often in some code bases. I don't consider
> try-except intuitive for a situation where the exception case isn't
> exceptional.
>
> default=None makes sense when you are used to dicts, .first() or
> .get_or_none() or .getnone() or .single() would be fine too.
>
>
> Ole
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/r8vZ2A9tIkgJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Sean Bleier]

JKM, I'm wondering if it would benefit the community to house
djangobench under https://github.com/django to give it more
visibility.  Just a thought.

On Thu, Oct 11, 2012 at 9:45 AM, ptone  wrote:
>
>
> On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>>
>>
>> That said - could Django be faster? Sure. *Anything* can be improved.
>>
>> So, if you've got a suggestion, make it. If you think URL resolving is
>> the source of the problem, propose a way to improve the speed of URL
>> resolvers. If you think the template language is the problem, propose
>> a fix.
>
>
> To do my part to increase the signal:noise.
>
> I'll point out that just as writing a failing test is a great way to augment
> a bug report - contributing or improving a benchmark for:
>
> https://github.com/jacobian/djangobench
>
> would be a good way to contribute to a discussion around a particular
> performance improvement you're interested in seeing happen.
>
> -Preston
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/kI7jNl7gYwEJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Daniel Moisset]

On Thu, Oct 11, 2012 at 2:00 PM, Marijonas Petrauskas  wrote:
> You can use:
>
> obj = next(iter(SomeModel.objects.filter(foo='bar')), None)
>
> The 'iter' part is not particularly elegant, but it's the only one-liner
> known to me.
>

obj, = SomeModel.objects.filter(foo='bar') or [None]

but we're getting deep into django-users land.

D.

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Łukasz Rekucki]

On 11 October 2012 10:20, Russell Keith-Magee  wrote:
>
> And don't just say "Why are Django's URL resolvers slow?". Do some
> profiling, and come back with an analysis of where the time is being
> spent and/or wasted.

FWIW, here's a link to a cProfile result for the mentioned
benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows
that we're calling get_language() 1.5mln times (read: for every
pattern), so that's definitely going to slow down things.

I'll try running the same with 1.3 and maybe 1.4 without the locale
mixin and post if I find anything interesting.

[1]: https://gist.github.com/3875701


-- 
Łukasz Rekucki

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.5: AUTH_USER_MODEL and GeoManager

[ptone]

On Thursday, October 11, 2012 12:51:07 AM UTC-7, Max wrote:
>
> Hi there,
> this is my first post here; hope I'm posting to the right group.
> I'm currently working on getting to run an 1.4-application (using a 
> profile model) on 1.5dev, using the the new (eagerly awaited by me) 
> custom user model.
> I used django.contrib.gis.db.GeoManager with my former profile-Model and 
> so I wanted to use it with my new custom user model, too.
> The following exception was thrown:
>
> " 'GeoManager' object has no attribute 'get_by_natural_key' "
>
> Hacking contrib/gis/db/models/manager.py and making GeoManager subclass 
> 'django.contrib.auth.models.UserManager' 
>
> instead of 'Manager' solved it for the moment.
>
> Maybe this is something that hasn't been thought of yet.
>
> I felt like I should post this.
>
>
Custom user objects require a custom manager that inherits from at least 
django.contrib.auth.models.BaseUserManager, which defines the 
get_by_natural_key method

Because the GeoManager defines a completely non-conflicting set of methods 
- you should be able to define your manager as:

class MyCustomGeoUserManager(BaseUserManager, GeoManager):

and then defining create_user and create_superuser per the docs

-Preston 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/4MpY9sSn164J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.