Re: Small problem with HttpResponseRedirect

As Ian said, Django does the right thing here according to my tests too, and generates the absolute URIs required by RFC 2616. If you've figured out some way to actually get location headers that are noncompliant, that would be a bug, but the handling of // is correct. -Paul -- You received

Re: Small problem with HttpResponseRedirect

On Mon, Dec 5, 2011 at 2:00 PM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Not sure if this should have a bug ticket raised or not.. wanted to get > core devs thoughts. > > > _redir = "//your/path/with/an/extra/slash/for/whatever/reason" >

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Mon, Dec 5, 2011 at 5:08 PM, Vinay Sajip wrote: > On Dec 6, 12:45 am, Ian Clelland wrote: > > After a lot of troubleshooting, and fun installing Python3.2 under > > virtualenv (Vinay, I think I ran into the same issue as you here: >

Re: Small problem with HttpResponseRedirect

To be more spesific: "Following the syntax specifications in *RFC 1808*, urlparse recognizes a netloc only if it is properly introduced by '//'. Otherwise the input is presumed to be a relative URL and thus to start with a path component." 6 Aralık 2011

Re: Small problem with HttpResponseRedirect

Maybe this is about second example in here: http://docs.python.org/library/urlparse.html#urlparse.urlparse ? 2011/12/6 Luciano Pacheco > On Tue, Dec 6, 2011 at 9:00 AM, Cal Leeming [Simplicity Media Ltd] < > cal.leem...@simplicitymedialtd.co.uk> wrote: > >> Not sure if this

Re: Small problem with HttpResponseRedirect

On Tue, Dec 6, 2011 at 9:00 AM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Not sure if this should have a bug ticket raised or not.. wanted to get > core devs thoughts. > > > _redir = "//your/path/with/an/extra/slash/for/whatever/reason" >

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 6, 12:45 am, Ian Clelland wrote: > After a lot of troubleshooting, and fun installing Python3.2 under > virtualenv (Vinay, I think I ran into the same issue as you > here:https://github.com/pypa/virtualenv/issues/194), I almost have the > complete > test suite running

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

After a lot of troubleshooting, and fun installing Python3.2 under virtualenv (Vinay, I think I ran into the same issue as you here: https://github.com/pypa/virtualenv/issues/194), I almost have the complete test suite running under MacPorts Python 3.2.2. The one unexpected error I am getting is

Re: Small problem with HttpResponseRedirect

On Mon, Dec 5, 2011 at 4:00 PM, Cal Leeming [Simplicity Media Ltd] wrote: > _redir = "//your/path/with/an/extra/slash/for/whatever/reason" > HttpResponseRedirect(_redir) > returns "Location: http://your/path/with/an/extra/slash/for/whatever/reason; > > _redir

Re: Django-nonrel patches

On Sat, Dec 3, 2011 at 4:36 PM, Jonas H. wrote: > On Jacob's suggestion in this thread [1] back in April, I split the diff > between Django trunk and Django-nonrel into logically separated patches. > > I uploaded most of them to the ticket tracker (a few things are still >

Small problem with HttpResponseRedirect

Not sure if this should have a bug ticket raised or not.. wanted to get core devs thoughts. _redir = "//your/path/with/an/extra/slash/for/whatever/reason" HttpResponseRedirect(_redir) returns "Location: http://your/path/with/an/extra/slash/for/whatever/reason; _redir =

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 7:08 pm, Alex Gaynor wrote: > It depends *why* it's slow.  If it's slow as a consequence of all the bytes > calls and extra encoding/decoding, yeah I'd say that's a blocker, because > it'll never improve otherwise.  On the other hand if it's slow because >

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 7:08 pm, Alex Gaynor wrote: > It depends *why* it's slow.  If it's slow as a consequence of all the bytes > calls and extra encoding/decoding, yeah I'd say that's a blocker, because > it'll never improve otherwise.  On the other hand if it's slow because >

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Mon, Dec 5, 2011 at 2:07 PM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/05/2011 11:56 AM, Jeremy Dunck wrote: > > Carl, to be clear, if py3 pg is slower, but py2 pg is still in line w/ > > baseline, would that block merge to trunk? It's

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 11:56 AM, Jeremy Dunck wrote: > Carl, to be clear, if py3 pg is slower, but py2 pg is still in line w/ > baseline, would that block merge to trunk? It's quite possible the > problem lies in psycopg, but I think merging (with caveat

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Mon, Dec 5, 2011 at 7:28 AM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/05/2011 08:10 AM, Vinay Sajip wrote: >> Not too bad for a first complete pass. Over two and a half hours to >> run, and that' s running from /dev/shm (IIUC effectively

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 3:15 pm, Carl Meyer wrote: > That sounds orders of magnitude slower than running the tests under > Postgres here - and I haven't done any of the pg-config tweaking others > have mentioned (not even turning fsync off). Which leads me to think > that either there is

Re: Feature proposal: models.CALL_DELETE or effective equivalent

Hi Carl, Thanks for the reply. My guess is that adding a new, optional Meta argument, (e.g. ``call_delete_on_fk_delete = True``) would be much simpler to implement. I used ``on_delete`` to make it easy to understand what I'm asking for, though if it is possible to achieve this way, I'd be willing

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 5:28 pm, Carl Meyer wrote: > > Not too bad for a first complete pass. Over two and a half hours to > > run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and > > with fsync = off. All else set to default values. Time to investigate > > Jeremy's link to

Re: Feature proposal: models.CALL_DELETE or effective equivalent

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 08:31 AM, Yo-Yo Ma wrote: > While I agree that signals allow for neat decoupling, they aren't as > DRY or quick as a simple field kwarg. Imagine you have 8 models that > have custom delete methods. Which is easier: A) avstracting the >

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

So, as a point of comparison, Postgres should take a 20-30% hit in performance from running under KVM-QEMU or Virtualbox. It's almost 50% under Xen. This is obviously looking worse than that. http://www.phoronix.com/scan.php?page=article=ubuntu_1110_xenkvm=7 I know, lies and benchmarks, but it's

Re: Feature proposal: models.CALL_DELETE or effective equivalent

On Dec 4, 10:46 pm, Justin Holmes wrote: > "hacks, signals, and/or patches" > > One of these things is not like the other While I agree that signals allow for neat decoupling, they aren't as DRY or quick as a simple field kwarg. Imagine you have 8 models that have

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 08:10 AM, Vinay Sajip wrote: > Not too bad for a first complete pass. Over two and a half hours to > run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and > with fsync = off. All else set to default values. Time to

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Vinay, On 12/05/2011 04:41 AM, Vinay Sajip wrote: [snip] > containing " IN ()", which the backend rejects as a syntax error]. I'm > running the full suite now, but I don't expect it to finish before the > end of the day :-( That sounds orders of

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 12:14 pm, Anssi Kääriäinen wrote: > As for test running speed: how fast is it for you? For me, using an old > laptop, the speed is around 20-30 minutes (can't test for accurate speed > right now). So, if it is much slower, you have something strange in your >

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 12:14 pm, Anssi Kääriäinen wrote: > On 12/05/2011 01:41 PM, Vinay Sajip wrote: > > The test_ticket10432 should not generate any query at all. The tests in > django/db/models/sql/where.py should ensure that in the case of empty > __in condition the query will

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On 12/05/2011 01:41 PM, Vinay Sajip wrote: I've eliminated many of the errors here, but a few remain, at least some of which are related to the psycopg2 driver under Python 3 [e.g. test_ticket10432 leads to a SQL query apparently legitimately containing " IN ()", which the backend rejects as a

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 11:30 am, Florian Apolloner wrote: > > Use a tablespace which lies in a ram disk, you can't get any faster than > that I/O wise ;) I've seen posts telling how to do this, but I had hoped to avoid the need for it ... Regards, Vinay Sajip -- You received this

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

On Dec 5, 12:57 am, Anssi Kääriäinen wrote: > > To speed up things, here are the tests that failed for me after the > fixes posted upthread: >  - cache >  - select_for_update >  - queries >  - admin_views > I've eliminated many of the errors here, but a few remain, at

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

Hi, On Monday, December 5, 2011 2:10:50 AM UTC+1, Vinay Sajip wrote: > > I've already done the fsync = off, but it didn't make that much > > difference :-( > Use a tablespace which lies in a ram disk, you can't get any faster than that I/O wise ;) -- You received this message because you are

Re: Deprecate change pk + save behavior for 1.4

On Dec 5, 11:43 am, Stephen Burrows wrote: > I've often longed for a "read-only" concept in ModelForms. For > example, if I want the "site" field to always have a certain value > (i.e. the current site) but also want to enforce multiple-column > uniqueness (i.e.

Re: Deprecate change pk + save behavior for 1.4

I've often longed for a "read-only" concept in ModelForms. For example, if I want the "site" field to always have a certain value (i.e. the current site) but also want to enforce multiple-column uniqueness (i.e. slug/site). I can write it myself, but it always feels like I shouldn't have to.