Amazon shows it as being released on Oct 22:
http://www.amazon.com/Professional-Python-Frameworks-Programming-Turbogears/dp/0470138092/ref=pd_bbs_12/104-9039171-6407132?ie=UTF8=books=1187871082=8-12
On 8/23/07, Ramdas S <[EMAIL PROTECTED]> wrote:
> Has someone seen this book?
>
>
Amazon shows that the book on Django will be published on March 26th
which is 1 1/2 weeks away. Does anyone know if that date is still
valid?
I'm anxiously waiting to order it.
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
I just moved to Dreamhost so I can start to work with Django as my
previous host wouldn't support it. I'd be curious to know if the
general concensus is that the speed difference is a "fcgi vs flup"
issue, or if there could be other factors at play. E.g.:
- Maybe the Dreamhost servers are
> I took a look and traced the bottleneck to lines 125 and 127 in
> viewPlan.html. The problem was as Malcolm hinted -- you're
> doing a foreign key lookup ({{ workout.workoutType.name }})
> for each iteration of the for loop.
>
> I changed line 55 of views.py to use select_related() instead
> of
The app I have is pretty simply as I'm just beginning so I didn't
bother to try and make it any smaller. I've ZIPped the entire project
directory and it can be downloaded here:
http://www.roadtoboston.com/media/RoadToBoston.zip
I have a batch file called runserver.cmd that would run the local
> It may take a couple more days to work this out. It's only been 48 hours
> since you posted the original problem and less than 24 hours since you
> posted a portion of your code that causes the problem. It is very
> unusual behaviour for Django; the templating code is normally very fast,
> but
-02-08 at 20:21 -0600, Derek Lee-Wo wrote:
> > > One more idea: It looks like you're doing foreign-key lookups in the
> > > rendering.
> > >
> > > {% for workoutWeek in workoutWeeks %}
> > > ...
> > > {% for workoutDay in workoutWeek.workouts %
I incorporated ReportLib to generate a PDF of the same data that I'm
trying to display on the web and the PDF gets created in about 2
seconds as compared to the template via Django which is taking 16-18
seconds.
Both routines share a common method that does all the data retrieval
and
> I did as you suggested and the call template.render() is where the
> 16-18 seconds are being spent. My next step is to add some timings to
> django.template.NodeList.render as you suggested.
I added a timing statement at the entrance and exit of render() and
just inside the foreach loop. I
> You'll want to do something like this, timing each line:
>
> from django.template import loader
>
> source, origin = find_template_source('your_template_name')
> template = get_template_from_string(source, origin, 'your_template_name')
> template.render(your_context)
>
> --
>
> It
> > My app does a bunch of database queries and processing and when I
> > timed that part, it all completes within 0.5 seconds, but the call to
> > render_to_response() takes 18 seconds. Needless to say, the end-user
> > experience isn't acceptable.
>
> I don't know if you are aware about the
I just started working with Django about a week ago and I love it. I
was able to get my first webapp up and running faster than I have with
various other technologies I've used in the past.
One problem I'm having though is the speed of the template rendering.
That is, the call to
12 matches
Mail list logo
