Re: Possible idea for removing global state in Django.

Le jeudi 17 octobre 2013 01:26:20 UTC+2, Russell Keith-Magee a écrit > What's wrong with thread local storage? Well, try this though experiment. > > Everywhere that you see the word "thread local", replace it with "global > variable". Now re-read your argument. > > It doesn't matter how you

Re: Backwards compatibility and field validation

Thank you for the detailed reply, much appreciated. I think the problem isn't just storing model validations with migrations, because it's probably good practice for any developer to assume that field data may be invalid (i.e. manual field/table changes, unknown validation bugs from previous

Re: Possible idea for removing global state in Django.

On Thu, Oct 17, 2013 at 4:24 AM, Jonathan Slenders < jonathan.slend...@gmail.com> wrote: > The global state problem is something that's been bothering me for a long > while, but after seeing a presentation of Alex Gaynor [1] from last year, I > started thinking about this again. > > The main

Re: An argument against mark_safe.

On Thu, Oct 17, 2013 at 3:30 AM, Jonathan Slenders < jonathan.slend...@gmail.com> wrote: > Currently, on python-ideas there is a discussion going on about taint > tracking in Python. It's tracking data that come from untrusted sources and > preventing it from being used in sensitive places. This

Re: Backwards compatibility and field validation

On Wed, Oct 16, 2013 at 12:15 AM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Sorry I should have made myself a little more clear. > > When I said "invalidating data inside your models" I was referring to any > previous data that was saved when the

Re: Backwards compatibility and field validation

On Tue, Oct 15, 2013 at 11:43 PM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Hello, > > I am trying to understand why field validators (model.full_clean()) are > not called for model.save() > > I've spent about an hour reviewing all the discussions/replies

Possible idea for removing global state in Django.

The global state problem is something that's been bothering me for a long while, but after seeing a presentation of Alex Gaynor [1] from last year, I started thinking about this again. The main problem is that you'd need to have a DjangoProject object which contains the root configuration and

An argument against mark_safe.

Currently, on python-ideas there is a discussion going on about taint tracking in Python. It's tracking data that come from untrusted sources and preventing it from being used in sensitive places. This video [1] from last year explains the problems very well. In noticed that we can do

Re: Feature request: New middleware method for "universal" decoration

Keyword argument to patterns() perhaps? On 16 Oct 2013 18:36, "Shai Berger" wrote: > On Tuesday 15 October 2013 11:49:32 Anssi Kääriäinen wrote: > > On Tuesday, October 15, 2013 8:23:38 AM UTC+3, gavi...@gmail.com wrote: > > > This topic was also discussed during the

Re: Feature request: New middleware method for "universal" decoration

On Tuesday 15 October 2013 11:49:32 Anssi Kääriäinen wrote: > On Tuesday, October 15, 2013 8:23:38 AM UTC+3, gavi...@gmail.com wrote: > > This topic was also discussed during the deprecation of > > TransactionMiddleware and the introduction of ATOMIC_REQUESTS. The > > existing middleware semantics

Re: #18659 -- Deprecating request.REQUEST

On Wednesday 16 October 2013 19:48:09 Aymeric Augustin wrote: > 2013/10/16 Javier Guerra Giraldez > > > yes, they're different, but is there any value in emphasizing the > > difference? > > The main value lies in emphasizing the difference between HTTP GET and HTTP > POST.

Re: #18659 -- Deprecating request.REQUEST

2013/10/16 Javier Guerra Giraldez > yes, they're different, but is there any value in emphasizing the > difference? > The main value lies in emphasizing the difference between HTTP GET and HTTP POST. That difference has security implications, especially with regards to CSRF.

Re: #18659 -- Deprecating request.REQUEST

+1 on removing it. It's usage reinforces incorrect assumptions about the meaning and behaviour of `request.POST` and `request.GET`. > It's hardly ever a good design pattern to handle GET and POST identically I'd phrase is as "It's hardly ever a good design pattern to handle query parameters

Re: #18659 -- Deprecating request.REQUEST

disclaimer: i'm in no way opposing the deprecation of request.REQUEST. still, i feel there are lots of bad reasons in PHP-land about discouraging use of that feature (typically some imagined security reasons). I'd like to see some good reasons besides aesthetics (yes, it's ugly) and duplication

Re: #18659 -- Deprecating request.REQUEST

On 2013-10-16 11:10, Javier Guerra Giraldez wrote: > On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger > wrote: > > However, it does so by blurring the distinction between GET and > > POST parameters, which like other people here, I find > > disturbing. > > care to elaborate about

Re: #18659 -- Deprecating request.REQUEST

On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger wrote: > However, it does so by blurring the distinction between GET and POST > parameters, which like other people here, I find disturbing. care to elaborate about that distinction? both are user-provided parameters included in

GIS: Oracle XE read only support in django.contrib.gis

Hi, I have opened a ticket on a method that seems to work to provide read only access to spatial (sdo_geometry) fields in an oracle database using oracle xe. See https://code.djangoproject.com/ticket/21273 In short, we can use the__getattribute__ method of the CLOB field returned by cx_Oracle

Re: #18659 -- Deprecating request.REQUEST

Another +1 for removing it, it makes it way too easy to do something unfortunate, and it's behavior is only really intuitive if you come from PHP, otherwise my first question is, "Where does it look first!?!" every time I see it used. Alex On Wed, Oct 16, 2013 at 8:14 AM, Shai Berger

Re: #18659 -- Deprecating request.REQUEST

On Wednesday 16 October 2013 15:52:56 John Paulett wrote: > I'll chime in with a counterpoint. > > request.REQUEST can be helpful in limited cases when the server application > simply does not care whether it is receiving data via a GET query string or > x-www-form-urlencoded POST and a different

Re: Backwards compatibility and field validation

I'd considered having a `validate` attribute on save(), but this feels unnecessary because we can already have model.full_clean(), having `validate` seems superfluous. One idea I'd had was to only validate fields which had changed. The reason for this is because we cannot assume data in the model

Re: #18659 -- Deprecating request.REQUEST

I'll chime in with a counterpoint. request.REQUEST can be helpful in limited cases when the server application simply does not care whether it is receiving data via a GET query string or x-www-form-urlencoded POST and a different clients can choose which form method is appropriate for its use

Re: #18659 -- Deprecating request.REQUEST

+1 to deprecating this. In the rare cases where it is useful (mainly 'next' for redirects) it is very easy to work around it not being there - request.GET.get('next', request.POST.get('next')) - so I see no reason for it to always exist. In most cases I feel its use is not a good idea™… Marc On

#18659 -- Deprecating request.REQUEST

The ticket now has a patch so I wanted to make sure the consensus is to more forward with this. Here's the rationale from the ticket : request.REQUEST provides indifferent access to request.GET or

Re: ImportError: cannot import name actions

Hi! On 10/15/2013 04:56 PM, rok wrote: > I have recently been testing the 1.6b4 tag with a new app we are > writing, using apache and wsgi. However, I could not get rid of the > following issue happening on every request: > > ... > [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] File >