Django 1.6 alpha 1 released • Hacker News Board

Re: Django 1.6 alpha 1 released

#31

Post by JshWright » Mon, May 27, 2013, 5:22 PM UTC

coldtea wrote: post #27

jacobian wrote: post #21

Earlier quoted context omitted.

Again, see my comment up-thread. Your assumptions are rather incorrect.

Yes, but his complaint is rather valid. Those that prepared the release notes made a mistake in not mentioning Python 3 related improvements / status.

jacobian acknowledged that oversight hours ago...

>Fact is, we just forgot to mention it. Django's working so well on Py3 that it kinda seems like no big deal any more, so we forgot to mention it in the release notes. I'll fix that once I get a chance.

Re: Django 1.6 alpha 1 released

#32

Post by natrius » Mon, May 27, 2013, 6:33 PM UTC

sdfjkl wrote: post #28

SiVal wrote: post #17

Earlier quoted context omitted.

Yes, but 1.5 claimed only "experimental support", adding that they thought it probably would work all right but didn't want to recommend Python 3 for production yet. The unqualified "yes, we now consider it ready and can recommend Python 3 for production," was promised for Django 1.6. They probably have achieved that goal, but the fact that there is no mention of it anywhere in a document that mentions so many other…

It works fine. I'm working on my 2nd Django project using Python 3.3. The only missing component is South, and that isn't part of Django (although it'd be nice if it were).

South supports Python 3 as of a couple of days ago.

http://www.aeracode.org/2013/5/22/south-08-migrations-and-dj...

Re: Django 1.6 alpha 1 released

#33

Post by vonseel » Mon, May 27, 2013, 6:40 PM UTC

I'm amazed by the rate of the Django releases lately; the core devs must be very busy.

Re: Django 1.6 alpha 1 released

#34

Post by jacobian » Tue, May 28, 2013, 4:00 AM UTC

foobarram wrote: post #29

jacobian wrote: post #25

Earlier quoted context omitted.

Not exactly. It's not proper connection pooling -- for that, you still should be using an external pool like pgbouncer. Instead this is a single persistent connection per thread. The speed improvement should be about the same, but you something like pgbouncer gives you more control over the number of connections and offers a ton of extra features.

Thank you very much for the clarification `jacobian` - I am assuming that django's connection pooling on 1.6 would still play nice with pgBouncer.

Mmmm.... I mean, it would, I guess, but I wouldn't recommend using both unless you can show a marked speed improvement over just using pgbouncer. A real connection is (probably) better than persistent connections, so you probably only need the one.

Now, I've not benchmarked this, so it's just a guess. Further, the specific performance characteristics will depend on your specific setup -- particularly upon where you have pgbouncer running -- so the only real answer is to benchmark and see.

New Relic does a good job showing time spent connecting to the db, fwiw, so you may want to give that a try.

Re: Django 1.6 alpha 1 released

#35

Post by jacobian » Tue, May 28, 2013, 4:01 AM UTC

coldtea wrote: post #27

jacobian wrote: post #21

Earlier quoted context omitted.

Again, see my comment up-thread. Your assumptions are rather incorrect.

Yes, but his complaint is rather valid. Those that prepared the release notes made a mistake in not mentioning Python 3 related improvements / status.

Yup, we made a mistake. You could help by submitting a patch to fix it, or you could just choose to be a jerk and give some random person shit for making a mistake.

Your choice.

Re: Django 1.6 alpha 1 released

#36

Post by foobarram » Tue, May 28, 2013, 10:20 AM UTC

jacobian wrote: post #34

foobarram wrote: post #29

Earlier quoted context omitted.

Thank you very much for the clarification `jacobian` - I am assuming that django's connection pooling on 1.6 would still play nice with pgBouncer.

Mmmm.... I mean, it would, I guess, but I wouldn't recommend using both unless you can show a marked speed improvement over just using pgbouncer. A real connection is (probably) better than persistent connections, so you probably only need the one. Now, I've not benchmarked this, so it's just a guess. Further, the specific performance characteristics will depend on your specific setup -- particularly upon where you h…

Thanks again for your answer - I have noted this down now. I will benchmark both cases (CONN_MAX_AGE and PgBouncer) and see which one is faster. Would like to thank you (!!) for the awesome python framework - Django.