Re: Deprecate change pk + save behavior for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2011 07:29 PM, Kääriäinen Anssi wrote: > At this point this is not the idea. The idea is to just disallow this > (assuming > multicolumn PK firstname, lastname): > > user = User(firstname = 'Jack', lastname = 'Smith') > user.save() >

RE: Deprecate change pk + save behavior for 1.4

""" On 12/02/2011 06:54 PM, Kääriäinen Anssi wrote: > I think I will pursuit the immutable PK approach, and see how it > works (back to square one). BTW are there -1 calls on this approach, > or the pk change tracking in general? I haven't been fully following this thread, but I will say that I'm

Re: Deprecate change pk + save behavior for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Anssi, On 12/02/2011 06:54 PM, Kääriäinen Anssi wrote: > I think I will pursuit the immutable PK approach, and see how it > works (back to square one). BTW are there -1 calls on this approach, > or the pk change tracking in general? I haven't

RE: Deprecate change pk + save behavior for 1.4

""" That's really too bad; I was hoping that that approach would work. (Also, I really hope nobody is using a FileField for a primary key ;) ) Is the problem here that we can't reliably tell whether the data that is going out to the DB layer has changed? I would think that no matter how the

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

If I get a little time this weekend I'll try this with a postgre backend. Awesome that this is being done and the Django looks to be more active. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

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

On Dec 2, 9:29 pm, Ian Kelly wrote: > I'm already planning to go through the Oracle tests this weekend to > get them ready for 1.4, so I'll run this through as well and let you > know how it goes.  Right now I expect failures even in 2.7. Great, I look forward to the

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

On Dec 2, 7:32 pm, Tomek Paczkowski wrote: > Most important: where to send all those beer pints? Heh. I do drink beer, but my liver would probably prefer it if someone were to send me something from my Amazon wishlist, which is on

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

On Dec 2, 6:34 pm, "Joe & Anne Tennies" wrote: > So, last time I saw, you had only run against sqlite. Do you need help > testing it against postgres, MySQL, and oracle (perhaps some unofficial > ones)? What about all the caching backends? Do we need tests Python 3 > equivalent

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

On Dec 2, 6:03 pm, Jacob Kaplan-Moss wrote: > > I'll try to spend the weekend writing/porting an app or two. If I can, > I'll let you know how it goes. That would be very useful feedback, thanks. Regards, Vinay Sajip -- You received this message because you are subscribed

Re: Sprint in San Francisco

January 7-8 sounds good to me. >  Have we thought about timeline on feature freeze, etc? Soon. I hope we feature freeze before then, and could spend a sprint triaging and killing release blockers. >  If anyone in the SF area would like to host the sprint, that would > be most welcome If we

Sprint in San Francisco

Hey all, With the 1.4 release coming up, I thought it'd be a good time to schedule a sprint to get in any ponies or help shake out bugs. I'm in San Francisco these days, which I hear is an OK place to try to host a sprint. Given the holidays coming up shortly, I was planning for just after

Re: Queries about CSRF design following penetration test

Sri: Of course you must make sure there's no XSS. You also must make sure there's no remote code execution, and that your memcached servers aren't running unauthenticated on a publicly exposed port. > If your website has a XSS vulnerability, there can be no CSRF protection. > This is because XSS

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

On Fri, Dec 2, 2011 at 11:34 AM, Joe & Anne Tennies wrote: > So, last time I saw, you had only run against sqlite. Do you need help > testing it against postgres, MySQL, and oracle (perhaps some unofficial > ones)? What about all the caching backends? Do we need tests Python 3

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

awesome guys. big kudos -- 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/-/R3_9KgskiusJ. To post to this group, send email to

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

Great news! \o/ -- 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/-/S_g1sXGEdCAJ. To post to this group, send email to

Re: Queries about CSRF design following penetration test

Paul's summary was - HTTPS, HSTS and validate Host header. I will add - you *must* also ensure there are no XSS vulnerabilities on your website. If your website has a XSS vulnerability, there can be no CSRF protection. This is because XSS makes it possible to steal the csrf as well as session

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

Most important: where to send all those beer pints? -- 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/-/4NW-QeNEBvAJ. To post to this group, send

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

So, last time I saw, you had only run against sqlite. Do you need help testing it against postgres, MySQL, and oracle (perhaps some unofficial ones)? What about all the caching backends? Do we need tests Python 3 equivalent tests for the ones that were skipped due to being Python 2-isms? What

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

2011/12/2 Vinay Sajip > The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with > the same codebase: > > Wohoo! Can't wait to try py3 with Django! :) Regards, Håkon Erichsen -- You received this message because you are subscribed to the Google Groups

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

On Fri, Dec 2, 2011 at 9:55 AM, Vinay Sajip wrote: > The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with > the same codebase: W! This is really fantastic news - I can't thank you enough for pushing this. I've just started scratching the surface and

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

Incredible, thanks! On Dec 2, 4:55 pm, Vinay Sajip wrote: > The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with > the same codebase: > > Python 2.7.2 > = > > Ran 4475 tests in 373.875s > > OK (skipped=90, expected failures=3) > > Python 3.2.2 >

Re: Deprecate change pk + save behavior for 1.4

On Thu, Dec 1, 2011 at 6:38 PM, Anssi Kääriäinen wrote: > On Nov 30, 2:26 pm, Kääriäinen Anssi wrote: > \> The other way is storing old_pk in model._state, and compare the PK to > > that when saving. If changed, error. This would work best if

RE: Deprecate change pk + save behavior for 1.4

""" Now for the funny part of this. I suspected that __setattr__ would make init slower. But using a little trick, __init__ is now actually almost 30% faster for a 10 field model. The trick is checking if setattr needs to be called. It needs to be called if the user has defined __setattr__ for

Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with the same codebase: Python 2.7.2 = Ran 4475 tests in 373.875s OK (skipped=90, expected failures=3) Python 3.2.2 = Ran 4420 tests in 364.044s OK (skipped=97, expected failures=2, unexpected successes=1) This

Re: Queries about CSRF design following penetration test

Good morning, I have also looked into this mechanism and I wanted to add to the discussion. Many of my thoughts regard not simply Django's "stock" behavior, but the ease with which a developer may unexpectedly expose their work to security vulnerabilities. One important note to remember is

Re: Deprecate change pk + save behavior for 1.4

On Dec 2, 4:38 am, Anssi Kääriäinen wrote: >   - Have the "I'm mutable" flag for fields. I don't know if this is > workable from performance standpoint. In practice the implementation > could be descriptor based for in-place mutable fields. I implemented POC of this and

Re: Deprecate change pk + save behavior for 1.4

On 2 December 2011 15:38, Anssi Kääriäinen wrote: > The bad part about do-nothing is that: >  - I really do not like the API of .save() not changing the PK, but > instead duplicating the object. Maybe I am alone here. Definitely not. Cheers, mwh -- You received this