Re: ImportError: cannot import name actions

[Ivan Kharlamov]

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
> "/home/rok/apps/django-trunk/django/contrib/gis/admin/__init__.py", line
> 2, in 
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] from
> django.contrib.admin import autodiscover, site, AdminSite, ModelAdmin,
> StackedInline, TabularInline, HORIZONTAL, VERTICAL
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1]   File
> "/home/rok/apps/django-trunk/django/contrib/admin/__init__.py", line 6,
> in 
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] from
> django.contrib.admin.sites import AdminSite, site
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1]   File
> "/home/rok/apps/django-trunk/django/contrib/admin/sites.py", line 3, in
> 
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] from
> django.contrib.admin import ModelAdmin, actions
> [Tue Oct 15 12:50:36 2013] [error] [client 127.0.0.1] ImportError:
> cannot import name actions
> 
> by doing the following change, I could get rid of what looked like a
> circular import issue:
> --- a/django/contrib/admin/sites.py
> +++ b/django/contrib/admin/sites.py
> @@ -1,6 +1,7 @@
>  from functools import update_wrapper
>  from django.http import Http404, HttpResponseRedirect
> -from django.contrib.admin import ModelAdmin, actions
> +from django.contrib.admin import ModelAdmin
> +from django.contrib.admin.actions import delete_selected
>  from django.contrib.admin.forms import AdminAuthenticationForm
>  from django.contrib.auth import REDIRECT_FIELD_NAME
>  from django.contrib.contenttypes import views as contenttype_views
> @@ -46,7 +47,7 @@ class AdminSite(object):
>  self._registry = {}  # model_class class -> admin_class instance
>  self.name = name
>  self.app_name = app_name
> -self._actions = {'delete_selected': actions.delete_selected}
> +self._actions = {'delete_selected': delete_selected}
>  self._global_actions = self._actions.copy()
>  
>  def register(self, model_or_iterable, admin_class=None, **options):
> 
> Switching to 1.5.4 resolves the issue as well (even though the sites.py
> code is the same). What is more, this did not occur in the development
> environment when using the runserver run.
> 
> Any clue?

Well, if this doesn't happen in the dev environment and does happen in
production, is there any chance that you're using gunicorn via
`gunicorn_django` command? If yes, try running the project with
`gunicorn` command instead.

I have seen some weird import errors which occured only when I was
running the project with `gunicorn_django` in conjunction with Django
1.6, but I didn't take time to debug and report them since
`gunicorn_django` command is deprecated and switching to `gunicorn`
command fixed everything.

Regards,
Ivan

> -- 
> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5fc43a85-0d0c-4c9f-baea-ac610a17ab68%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/525E3FA9.1040503%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

#18659 -- Deprecating request.REQUEST

[Tim Graham]

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 request.POST (PHP 
style).

This attribute is a legacy from the pre-1.0 days, when you could access the 
GET or POST data using dict syntax on the request object. request.REQUEST was 
introduced in 1.0 to make this operation more explicit, with an easy 
upgrade path.

It's hardly ever a good design pattern to handle GET and POST identically, 
and it's our responsibility not to provide tools who are more likely to 
result in bad code than anything else. So I think it's time to deprecate 
this attribute.

We could deprecate django.utils.datastructures.MergeDict at the same time — 
it's a 100-lines long class whose sole purpose is to support request.REQUEST
.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d5946498-942d-4f47-8446-4eebfdf64f7c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Marc Tamlyn]

+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 16 Oct 2013 12:14, "Tim Graham"  wrote:

> 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 request.POST 
> (PHP
> style).
>
> This attribute is a legacy from the pre-1.0 days, when you could access
> the GET or POST data using dict syntax on the request object.
> request.REQUEST was introduced in 1.0 to make this operation more
> explicit, with an easy upgrade path.
>
> It's hardly ever a good design pattern to handle GET and POST identically,
> and it's our responsibility not to provide tools who are more likely to
> result in bad code than anything else. So I think it's time to deprecate
> this attribute.
>
> We could deprecate django.utils.datastructures.MergeDict at the same time
> — it's a 100-lines long class whose sole purpose is to support
> request.REQUEST.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d5946498-942d-4f47-8446-4eebfdf64f7c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GQUrWxjZ8Z_vfNHPbxXMxWBFyvbQgDkUn9dqatKvcR4A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[John Paulett]

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 case (e.g. possibly due to query
string length
restrictions  in some browsers).

I won't claim this approach is ideal, but I have found it useful on
occasion.  Also, I acknowledge that a simple replacement could be "REQUEST
= request.POST or request.GET".  If request.REQUEST ends up being removed,
I would not be upset, but I did want to state that I use it.

John


On Wed, Oct 16, 2013 at 8:04 AM, Marc Tamlyn  wrote:

> +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 16 Oct 2013 12:14, "Tim Graham"  wrote:
>
>> 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
>> request.POST (PHP style).
>>
>> This attribute is a legacy from the pre-1.0 days, when you could access
>> the GET or POST data using dict syntax on the request object.
>> request.REQUEST was introduced in 1.0 to make this operation more
>> explicit, with an easy upgrade path.
>>
>> It's hardly ever a good design pattern to handle GET and POST identically,
>> and it's our responsibility not to provide tools who are more likely to
>> result in bad code than anything else. So I think it's time to deprecate
>> this attribute.
>>
>> We could deprecate django.utils.datastructures.MergeDict at the same
>> time — it's a 100-lines long class whose sole purpose is to support
>> request.REQUEST.
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d5946498-942d-4f47-8446-4eebfdf64f7c%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1GQUrWxjZ8Z_vfNHPbxXMxWBFyvbQgDkUn9dqatKvcR4A%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANRBGvZMkbasbBPbnHfHT%3D%2Bv8F-2%3DBwXFYrrbt9PUK9UOAxLGw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Cal Leeming [Simplicity Media Ltd]]

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 from previous save()
will validate correctly on this save() (i.e. in the event of validation
rules changing). However the concept of only validating changed fields
seems confusing and likely to sting a lot of people.

Ultimately I think code based validation cannot be enforced at the model
layer for these reasons, with the exception of IntegrityError raised from
db constraints (which in my opinion is completely different to validations
in code).

I'd like to hear what a core dev has to say on the matter, at the very
least I think this is worthy of a docs patch to explain this more clearly
to users.

Cal


On Wed, Oct 16, 2013 at 5:20 AM, poswald  wrote:

> One problem with it as you've found is that you sometimes do want control
> over it on a per-model or even per-instance (per-save) basis. One way to
> deal with this is to create something like the following that you can
> extend in your models:
>
> class ValidatedModel(models.Model):
> def save(self, validate=True, *args, **kwargs):
> if validate:
> self.full_clean()
> super(ValidatedModel, self).save(*args, **kwargs)
>
> class Meta:
> abstract = True
>
>
> This helps you if you're trying it follow the 'fat model' philosophy and
> centralize the validation logic down out of the forms and into the model
> layer. It might end up validating twice if used in a model form though, I'm
> not sure. I personally wouldn't be against having a setting to change in
> the project-wide default behavior in a future Django version, but I think
> the ability to override it is important.
>
>
>
>
> On Wednesday, October 16, 2013 1:15:04 AM UTC+9, Cal Leeming [Simplicity
> Media Ltd] 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 validator was set to a minimum length
>> of 4 characters. By then changing the validator to be 5 characters, you are
>> effectively breaking save() on any data that was saved before that point,
>> and the ability to fix the model data may not be available in that specific
>> save() context. For example, a cron job that updates a "last_checked" field
>> on the user would not necessarily have data relevant to changes in the
>> users phone number (which could have its min/max length changed at any
>> point in the validators life time).
>>
>> Hope that makes more sense
>>
>> Cal
>>
>>
>> On Tue, Oct 15, 2013 at 5:12 PM, Cal Leeming [Simplicity Media Ltd] <
>> cal.l...@**simplicitymedialtd.co.uk> wrote:
>>
>>> I've been thinking about this a little bit more, and it seems that the
>>> design approach of validating on save() is not entirely correct.
>>>
>>> For example, say you have a validator that ensures a field must be at
>>> least 4 characters long, and a few months later the validation is then
>>> changed to be 5 characters long. This means any save() call on that field
>>> (which may include a modification to a field which is unrelated to the
>>> change being made) will then stop that save from happening. By applying the
>>> validation at the model level, you are then potentially invalidating data
>>> inside your models. This is fine for forms, because it can be handled at
>>> the user side (by returning a form error saying X field is incorrect), but
>>> would cause problems at the model layer.
>>>
>>> I think by design it would be very wrong to validate the model fields at
>>> the point of save(), despite seeming like it would be the correct thing to
>>> do.
>>>
>>> Could someone please verify if I have come to the correct conclusion
>>> here?
>>>
>>> Cal
>>>
>>>
>>> On Tue, Oct 15, 2013 at 4:43 PM, Cal Leeming [Simplicity Media Ltd] <
>>> cal.l...@**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 on this
 subject;
 http://www.xormedia.com/**django-model-validation-on-**save/
 http://stackoverflow.com/**questions/4441539/why-doesnt-**
 djangos-model-save-call-full-**clean
 https://code.djangoproject.**com/ticket/13100
 https://groups.google.com/**forum/#!topic/django-**
 developers/uIhzSwWHj4c

 From what I can tell this was rejected on the basis of breaking
 backwards compatibility.

>>

Re: #18659 -- Deprecating request.REQUEST

[Shai Berger]

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 clients can choose which form
> method is appropriate for its use case (e.g. possibly due to query
> string length
> restrictions  in some browsers).
> 
> I won't claim this approach is ideal, but I have found it useful on
> occasion.  Also, I acknowledge that a simple replacement could be "REQUEST
> = request.POST or request.GET".  If request.REQUEST ends up being removed,
> I would not be upset, but I did want to state that I use it.
> 
There is a fine point this seems to miss: The current REQUEST isn't equivalent 
to "request.POST or request.GET", but is a merge of the two; it supports a 
login form posted to a url like https://example.com/login/?next=eg which your 
suggestion wouldn't deal with well.

However, it does so by blurring the distinction between GET and POST 
parameters, which like other people here, I find disturbing.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201310161814.07961.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Alex Gaynor]

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  wrote:

> 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 clients can choose which form
> > method is appropriate for its use case (e.g. possibly due to query
> > string length
> > restrictions  in some
> browsers).
> >
> > I won't claim this approach is ideal, but I have found it useful on
> > occasion.  Also, I acknowledge that a simple replacement could be
> "REQUEST
> > = request.POST or request.GET".  If request.REQUEST ends up being
> removed,
> > I would not be upset, but I did want to state that I use it.
> >
> There is a fine point this seems to miss: The current REQUEST isn't
> equivalent
> to "request.POST or request.GET", but is a merge of the two; it supports a
> login form posted to a url like https://example.com/login/?next=eg which
> your
> suggestion wouldn't deal with well.
>
> However, it does so by blurring the distinction between GET and POST
> parameters, which like other people here, I find disturbing.
>
> Shai.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201310161814.07961.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFRnB2VkKvt7%2BEm7jV71DAbXi8iMG4Bii3FGvuPXTGNKdzAwbg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[vinhussey]

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 to access the SDO_GEOMETRY object and to generate WKT, like 
this:

>>> g_ewkt = "SRID:%s:POINT(%f %f)" % 
>>> (str(int(g.__getattribute__('SDO_SRID'))), 
>>> g.__getattribute__('SDO_POINT').X, g.__getattribute__('SDO_POINT').Y)
>>> g_ewkt
'SRID:82086:POINT(162913.389524 340748.357977)'

The Oracle documentation explains in detail how the object works, so accessing 
a range of geometry types (if not all types) as wkt appears to be feasible.

I'd be grateful on pointers or assistance (or would be happy to help someone 
who has more familiarity with django.contrib.gis) to move this on.

I understand from comments on the wiki and in the docs that this may be of use 
to a range of users, if only as a way to transfer legacy data to postgres 
(which is my use case).

Thanks
Vincent 


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9cd84960-1fa2-4832-b5aa-35cec451a753%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Javier Guerra Giraldez]

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 the request.  the only difference i see is
about encoding.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFkDaoRneuFj3y_N7hDtgDohygeuQM3e0w42-gN7gtqArhADUw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Tim Chase]

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 that distinction?  both are user-provided
> parameters included in the request.  the only difference i see is
> about encoding.

Because they're sent different ways.  POST variables in the request
body, and GET parameters are in the URL.  But it's possible that a
parameter is provided via *both*, and (as Alex notes) the first
question in such a case is "where does it look first?"

I'm +1 on the eventual removal, possibly with a footnoted function
that lets you request the fallback easily if needed.  It's a
one-liner as Marc details:

  request.GET.get(key, request.POST.get(key))

or

  request.POST.get(key, request.GET.get(key))

depending on the priority you want.

-tkc





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20131016112949.68b9d342%40bigbox.christie.dr.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Javier Guerra Giraldez]

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 of functionality.


On Wed, Oct 16, 2013 at 11:29 AM, Tim Chase
 wrote:
> 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 that distinction?  both are user-provided
>> parameters included in the request.  the only difference i see is
>> about encoding.
>
> Because they're sent different ways.  POST variables in the request
> body, and GET parameters are in the URL.


same origin: the browser or any http client

same destination: the web app

same transport: the http request

encoded in different parts of the request (body vs url).

yes, they're different, but is there any value in emphasizing the difference?


-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFkDaoRgoDbLr4WEc43w%3DRc8yBMG%2B66LDkMFx_F95vJQyLELGw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Tom Christie]

+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 and request bodies identically", but otherwise exactly this, yes.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3e98864c-ba33-48bf-b693-8006e786dea5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Aymeric Augustin]

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.

While pour point is technically valid as far as request.GET and
request.POST are concerned, in practice they're so commonly used as a
metonymy for HTTP GET and HTTP POST that it's worth having a strong stance
on keeping them separate.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mXpmgE-kzMV9Bj-X%2BrUtoSJf493O11C6zo0itVOorn8Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

[Shai Berger]

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. That difference has security implications, especially with regards to
> CSRF.
> 
Also, GET is supposed to be a "read only" operation.

http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201310161955.32716.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Shai Berger]

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 can't guarantee that  __exit__ (during
> > process_response) will get called no matter what, necessitating the
> > setting that invokes BaseHandler.make_view_atomic. make_view_atomic
> > implements basically what you're suggesting, for one specific case
> > (DB/ORM code in the front controller, ick!).
> > 
> 
> I am not suggesting using the above process() example in Django. The
> semantics for process_exception() in particular are backwards incompatible.
> It is just an example that you can achieve what is currently available with
> process_request(), process_response() and process_exception() methods, but
> with obvious semantics.
> 

I think the middlewares have grown a little complicated, and I'd try to avoid 
adding functionality there. That said, the feature of universal decoration 
seems like it is worthwhile. I'd try to see if it can be added through the 
urls mechanism instead -- you'd get behavior that is more like a decorator, in 
the sense that decoration would happen only once.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201310162036.05529.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Marc Tamlyn]

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 deprecation of
> > > TransactionMiddleware and the introduction of ATOMIC_REQUESTS. The
> > > existing middleware semantics can't guarantee that  __exit__ (during
> > > process_response) will get called no matter what, necessitating the
> > > setting that invokes BaseHandler.make_view_atomic. make_view_atomic
> > > implements basically what you're suggesting, for one specific case
> > > (DB/ORM code in the front controller, ick!).
> > >
> >
> > I am not suggesting using the above process() example in Django. The
> > semantics for process_exception() in particular are backwards
> incompatible.
> > It is just an example that you can achieve what is currently available
> with
> > process_request(), process_response() and process_exception() methods,
> but
> > with obvious semantics.
> >
>
> I think the middlewares have grown a little complicated, and I'd try to
> avoid
> adding functionality there. That said, the feature of universal decoration
> seems like it is worthwhile. I'd try to see if it can be added through the
> urls mechanism instead -- you'd get behavior that is more like a
> decorator, in
> the sense that decoration would happen only once.
>
> Shai.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201310162036.05529.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FUXFDPOvEi-wm%2BW1RAQpLMpJowvQ52TJsNuWMOoaT9rw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

An argument against mark_safe.

[Jonathan Slenders]

 

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 better in Django. We already have mark_safe, but 
what does such a SafeText mean? Safe as HTML, javascript, css, SQL or even 
something else? We know it's usually HTML, but that's not always the case.

Some people still have javascript in their templates and they use template 
tags inside their javascript. :(

Some people use the templating engine even for other stuff then generating 
HTML. The point is that we can't assume that "safe" means "safe as HTML". 
We have many languages in the web and HTML is just one of them.

I propose some changes that are backwards compatible for 
django.utils.safestring:
We should rename SafeText to HtmlText. Further we should not expect people 
to call format_html.

Instead of mark_safe, I propose that we call:
HtmlText(' %s ')
Explicitely annotating a string as HTML.

Instead of format_html, I propose that we do:
HtmlText(' %s ') % 'unsafe text'
Like django.utils.SafeText.__add__, we can implement SafeText.__mod__

I think that string interpolation feels more natural. (Or for those who 
prefer .format(), we can add that method to HtmlText.)

It can also be possible to stack escaping filters in the future:
HtmlText('%s') % JavascriptText("function() { echo '%s'; 
}") % 'hello world'
(implementing JavascriptText can be hard, as escaping is different in 
different parts of the code.)

Further, I would deprecate mark_for_escaping and EscapeData. [2] There 
should never be a reason to call this function.

Any suggestions?

[1] http://www.youtube.com/watch?v=WmZvnKYiNlE
[2] mark_for_escaping = lambda s: str(s) # Actually: mark_for_escaping == 
str

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8767da03-070b-4819-8d95-a7787cacd258%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Possible idea for removing global state in Django.

[Jonathan Slenders]

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 you'd have to somehow pass that object 
around everywhere.

Maybe I'm not the first to think about this, but what's wrong with 
thread-local-storage? In Django, we have a huge advantage above nodejs in 
that there's only one active request per thread and that request should 
belong to only one DjangoProject instance. (We don't have unexpected 
contextswitches in the same thread, like in Twisted or Tulip. -- We can 
make that assumption.)

Actually we are already using threadlocals for the current active language 
[2], so I don't see any reason for not using the same approach to keep 
track of the currently active DjangoApplication object.

It's not a really small project, but not impossible huge either. The most 
important parts of the code that need to be changed to use this thread 
local are:

* django.conf.settings:
We don't want to break that API, so the settings object should become a 
proxy that knows the current active project and returns the correct 
settings.

* the reverse() functions (and a few others) from URL patterns.
URL patterns depend on the application.

* Django models:
That's the harder one. MyModel.objects.get() needs to know the settings, in 
order to know what the current database is.


I would propose a python context manager to move from one project to 
another, if you ever have to. Say that you want to query a model from 
another project, you can do this:

other_django_project = DjangoProject.from_settings_file(my_project_settings)
with other_django_project.activate():
MyModel.objects.get()

manage.py should look like this:

if __name__ == '__main__':
django_project = DjangoProject.from_settings_file(my_project_settings)
with django_project.activate():
execute_from_command_line(sys.argv)


And for the flask-lovers which don't like automatic code generation and 
singleton patterns, they can just use the DangoProject constructor:

if __name__ == '__main__':
django_project = DjangoProject(
url_patterns=root_url_patterns,
installed_apps=[ ... ],

)
with django_project.activate():
execute_from_command_line(sys.argv)


For the why of all this, I refer to the presentation of Alex, but the main 
advantages are that it becomes much more easy to integrate Django projects 
in other Python projects and that unit testing becomes easier: you don't 
have a global state.

What do you think? I don't see real backward-compatibility issues that we 
can't solve. Do I forget something?

Cheers,
Jonathan


[1] https://www.youtube.com/watch?v=0FD510Oz2e4
[2] 
https://github.com/django/django/blob/master/django/utils/translation/trans_real.py#L23

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7dd166af-f8d6-4838-9a34-480ef5e5581c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Russell Keith-Magee]

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 on this
> subject;
> http://www.xormedia.com/django-model-validation-on-save/
>
> http://stackoverflow.com/questions/4441539/why-doesnt-djangos-model-save-call-full-clean
> https://code.djangoproject.com/ticket/13100
> https://groups.google.com/forum/#!topic/django-developers/uIhzSwWHj4c
>
> From what I can tell this was rejected on the basis of breaking backwards
> compatibility.
>
> It is unclear whether this would have been desired behavior had backwards
> compatibility not been an issue.
>
> It also seems to me that it would be possible to maintain backwards
> compatibility by using settings flags to determine the default behavior,
> albeit at the cost of increased complexity.
>
> So I have four questions;
>
> 1) Without taking backwards compatibility into consideration, is it
> reasonable to expect field validation automatically upon calling
> model.save()
>

Yes. Based on the original discussions (as I recall them), this wasn't in
question -- the problem was entirely backwards compatibility.


> 2) At what point would Django devs be willing to break backwards
> compatibility? Would this be considered on 2.x, or is it life time?
>

Well… ideally never. :-)

Pragmatically, we will make backwards compatible changes as long as there's
a clear migration path. The version number isn't something to get hung up
on; I'm not expecting 2.0 to be a "massive change" release in the same way
that Python 3.0 was. If we can get the solution right, we'll just do it,
not wait for a particular version number.

The approach we've taken to backwards incompatibility issues is to
introduce them slowly -- to provide lots of warnings that something is
going to change, provide opt-in for those that want to migrate, and ensure
that all new projects use the new behaviour. The change to the {% url %}
tag, for example, has taken almost 4 years to complete, which has given
everyone plenty of time to adapt.

3) Could backwards compatibility not be maintained by means of a flag in
> settings? For example, settings.MODEL_VALIDATE_ON_SAVE=True would cause the
> validation to be handled using the new approach?
>

Historically, we're not wild on introducing new settings, especially for
behaviour changes. However, we obviously need to have a way to flag 'use
the new behaviour'. The only other option I can think of would be a Meta
flag on individual models, but that obviously makes it difficult to turn on
the feature project-wide.

4) Assuming this cannot/will not be implemented, what would be the most
> suitable workaround? Are there any risks in calling full_clean() without
> ever using ModelForm? Should ModelForm always be used instead of using a
> model directly? etc.
>

At the simplest level, rewriting Model.save() to invoke Model.full_clean()
should be all the workaround you need.

As for risks - none that I can think of. Model validation is independent of
the forms framework; you can use model validation without ever using
ModelForms.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq849zb2F9H-WH%2BBrB8PFVxab596m4VRbRExGpVgF98nfd9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Russell Keith-Magee]

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 validator was set to a minimum length
> of 4 characters. By then changing the validator to be 5 characters, you are
> effectively breaking save() on any data that was saved before that point,
> and the ability to fix the model data may not be available in that specific
> save() context. For example, a cron job that updates a "last_checked" field
> on the user would not necessarily have data relevant to changes in the
> users phone number (which could have its min/max length changed at any
> point in the validators life time).
>
> Hope that makes more sense
>
> Your analysis is correct, but you're possibly over thinking this a bit.

Consider a world in which model validation *was* on by default. You write
some models with a char field, and you insert some data. All valid, all
saved successfully. Now you change your models and add a validation
condition. You've just exposed yourself to exactly the same situation,
without feature-level backwards compatibility ever being part of the
picture.

What this highlights is that migration needs to be part of the whole
solution. At the very least, as part of adding default model validation,
we'd need to document the fact that all existing data must be assumed to be
potentially invalid, and provide an easy way to force validation.
Unfortunately, there's not sure I see any easy way to do this other than a
"for model in database: model.save()" loop.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848-%3DwSerY4HT9zAcff9YVtjQLm7Xf6EmA_JhF3MX7xFkA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: An argument against mark_safe.

[Russell Keith-Magee]

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 video [1] from last
> year explains the problems very well.
>
> In noticed that we can do better in Django. We already have mark_safe, but
> what does such a SafeText mean? Safe as HTML, javascript, css, SQL or even
> something else? We know it's usually HTML, but that's not always the case.
>
> Some people still have javascript in their templates and they use template
> tags inside their javascript. :(
>
> Some people use the templating engine even for other stuff then generating
> HTML. The point is that we can't assume that "safe" means "safe as HTML".
> We have many languages in the web and HTML is just one of them.
>
> I propose some changes that are backwards compatible for
> django.utils.safestring:
> We should rename SafeText to HtmlText. Further we should not expect people
> to call format_html.
>
> Instead of mark_safe, I propose that we call:
> HtmlText(' %s ')
> Explicitely annotating a string as HTML.
>
> Instead of format_html, I propose that we do:
> HtmlText(' %s ') % 'unsafe text'
> Like django.utils.SafeText.__add__, we can implement SafeText.__mod__
>
> I think that string interpolation feels more natural. (Or for those who
> prefer .format(), we can add that method to HtmlText.)
>
> It can also be possible to stack escaping filters in the future:
> HtmlText('%s') % JavascriptText("function() { echo '%s';
> }") % 'hello world'
> (implementing JavascriptText can be hard, as escaping is different in
> different parts of the code.)
>
> Further, I would deprecate mark_for_escaping and EscapeData. [2] There
> should never be a reason to call this function.
>
> Any suggestions?
>
I can't fault your reasoning -- "safe" isn't a universal concept, and we
don't just generate HTML. There's already been a couple of bugs raised
about escaping in JavaScript IIRC.

Your proposed approach certainly sounds like a good starting point. I'm
sure there will be plenty of devil in the detail -- not the least of which,
how do you handle this in templates which can have mixed content (e.g., a
HTML page with JavaScript and CSS content embedded).

>From an implementation point of view, we can't just remove mark_safe
arbitrarily -- we'd need to have a migration plan in place, so that all the
existing code out there that is using mark_safe continues to work
(presumably interpreting safe text as safe HTML in the interim).

The other problem is finding someone to volunteer to actually do the work
:-) What you've described isn't a small undertaking.

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848dgvhOXL_FKWbYUd08%2BcdzthHNwNhA25ZEs2Ot_iHmyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Possible idea for removing global state in Django.

[Russell Keith-Magee]

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 problem is that you'd need to have a DjangoProject object which
> contains the root configuration and you'd have to somehow pass that object
> around everywhere.
>
> Maybe I'm not the first to think about this, but what's wrong with
> thread-local-storage?
>

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 gussy it up -- a thread local is a global
variable, with all the software engineering consequences that follow from
that, including increased coupling, decreased cohesion, complications for
testing, and so on.


> In Django, we have a huge advantage above nodejs in that there's only one
> active request per thread and that request should belong to only one
> DjangoProject instance. (We don't have unexpected contextswitches in the
> same thread, like in Twisted or Tulip. -- We can make that assumption.)
>

Yet. :-)

I don't know that we can rely on this being true for all time.

(This is an admittedly weak argument -- I certainly wouldn't base any
objection to thread locals on this alone)

Actually we are already using threadlocals for the current active language
> [2], so I don't see any reason for not using the same approach to keep
> track of the currently active DjangoApplication object.
>

You're correct -- however, I'd call this a wart, not a pattern to be
followed. If we were in a position to remove these thread locals, I would.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848XP6mqctJ3dkMVKbzMkpk%3DChETGy3Ws_oORt9xnArzfA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Cal Leeming [Simplicity Media Ltd]]

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 releases, buggy migration scripts etc). And a
for/model.save() loop would only work if auto-repair was feasible, in which
case the developer has to decide how to handle validation failures at
certain points in the code. The typical scenarios you'd handle when
encountering invalid data would be to ignore, repair or error - depending
on where you are within the code.

The approaches that come to mind are;

1) save(validate=True)
This still feels superfluous because we can just call full_clean() before
save().

2) full_clean() then save()
This works but you have to manually check the errors to see if it was old
or new data that causes validation

3) save(validate_only_changes=True) OR
full_clean(validate_only_changes=True)
Feels a bit better as it allows me to handle background jobs gracefully,
say a cron that is failing on a record that it doesn't know/need at that
point of execution.

4) CharField(validate_old=True)
This would not allow context specific handling (i.e. we want to enforce
validate old if we have a user request because we can ask them for updated
info, but do not enforce validate when inside a background job which does
not have the necessary context to request repair)

>From what I can tell, 3 would be a good approach based on the logic of
making it easier for the developer to decide how the failed validation
should be handled at certain points in the code.

Do you think that `save(validate_only_changes=True)` would be a good
approach (worthy of a patch), or am I over-engineering this problem?

Cal


On Thu, Oct 17, 2013 at 12:08 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> 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 validator was set to a minimum length
>> of 4 characters. By then changing the validator to be 5 characters, you are
>> effectively breaking save() on any data that was saved before that point,
>> and the ability to fix the model data may not be available in that specific
>> save() context. For example, a cron job that updates a "last_checked" field
>> on the user would not necessarily have data relevant to changes in the
>> users phone number (which could have its min/max length changed at any
>> point in the validators life time).
>>
>> Hope that makes more sense
>>
>> Your analysis is correct, but you're possibly over thinking this a bit.
>
> Consider a world in which model validation *was* on by default. You write
> some models with a char field, and you insert some data. All valid, all
> saved successfully. Now you change your models and add a validation
> condition. You've just exposed yourself to exactly the same situation,
> without feature-level backwards compatibility ever being part of the
> picture.
>
> What this highlights is that migration needs to be part of the whole
> solution. At the very least, as part of adding default model validation,
> we'd need to document the fact that all existing data must be assumed to be
> potentially invalid, and provide an easy way to force validation.
> Unfortunately, there's not sure I see any easy way to do this other than a
> "for model in database: model.save()" loop.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848-%3DwSerY4HT9zAcff9YVtjQLm7Xf6EmA_JhF3MX7xFkA%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHKQagFR811sPZPyvKgqDUndJx-rAVFHWT6O8N4kpZFBKxsXZg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Possible idea for removing global state in Django.

[Jonathan Slenders]

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 gussy it up -- a thread local is a global 
> variable, with all the software engineering consequences that follow from 
> that, including increased coupling, decreased cohesion, complications for 
> testing, and so on.
>
 

 It is a safe convention, I think. Actually every variable on the call 
stack is a thread local, because every thread has its own stack. In python 
it is possible to read variables from another thread (frame inspection), 
but you just don't do that.

A thread local is a persistent global -- I know --, but if you let it 
behave like a call stack, using context managers in Python, then it's not 
that different from a real local variable. the difference is that a 'real' 
local is on the interpreter's stack, while a thread local is in a 
pure-python stack. Both appear local.
The important part is that these stacks should look identical before and 
after execution of every function call, so that you don't have side 
effects. Python's "with"-statement is amazing at handling this.

Yes, it is more implicit than passing objects around, but it is safe. I 
think that it's also the only option we have.

Personally, for the active language, I would make that a stack as well, and 
deprecate language.activate like it is now.

with language.activate('en'):
do_something();

About relying on that we won't have unexpected context switches in the same 
thread. That would be a safe assumption. There is one exception, called 
Gevent. what Gevent does, is patching IO routines and swapping the current 
call stack for another using a C-extension. That's a dangerous practice, 
which is unsafe by design (Also why Guido van Rossem only wants to have an 
explicit 'yield' for coroutinus.) I'm not sure, but if we want to support 
gevent with thread locals, we meight need to hook into gevent and swap our 
pure-python stacks as well.

Hopefully that explains why I think that thread-locals are not that bad as 
they look.



 
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/78f6a3dc-c84c-4998-afa9-c85ae20efa91%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Anssi Kääriäinen]

On Wednesday, October 16, 2013 8:36:05 PM UTC+3, Shai Berger wrote:

> I think the middlewares have grown a little complicated, and I'd try to 
> avoid 
> adding functionality there. That said, the feature of universal decoration 
> seems like it is worthwhile. I'd try to see if it can be added through the 
> urls mechanism instead -- you'd get behavior that is more like a 
> decorator, in 
> the sense that decoration would happen only once. 
>

I hacked together a branch where middlewares could define wrap_request and 
wrap_view methods in addition to all existing process_* methods. The 
wrap_request and wrap_view methods are call-through. It turns out that it 
will be impossible to both bubble up exceptions through wrap_* methods 
while also supporting current middleware semantics. Currently exceptions 
get converted immediately to 500 responses. Doing that and also raising the 
exception through the stack is obviously impossible.

Allowing view wrapping in urls.py seems like a good solution. It would 
allow for what ATOMIC_REQUESTS does currently. And more - it would allow 
wrapping just part of your views, not all of them. Having the ability to 
apply permission_required to a collection of views from urls.py seems like 
a nice feature.

That still leaves whole request wrapping into impossible to achieve state. 
Maybe guarantee that all process_response methods are ran even if some of 
the raise exceptions is enough?

Currently there is no guarantee that all process_response methods get 
called. It seems that support for that would be fairly small backwards 
incompatible change. See: 
https://github.com/akaariai/django/commit/cc459994bb7899e744471dcb7ec034e6e1c310af.
 
This would add a guarantee that if process_request is called, then matching 
process_response gets called, too. Notable there is still no guarantee that 
if process_response is called, then process_request was also called. But 
changing that isn't easy to do.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98bd7629-38f1-409e-b2c1-1a058ed3559e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Possible idea for removing global state in Django.

[Aymeric Augustin]

On Oct 17, 2013 7:13 AM, "Jonathan Slenders" 
wrote:
> There is one exception, called Gevent. what Gevent does, is patching IO
routines and swapping the current call stack for another using a
C-extension. That's a dangerous practice, which is unsafe by design (Also
why Guido van Rossem only wants to have an explicit 'yield' for
coroutinus.) I'm not sure, but if we want to support gevent with thread
locals, we meight need to hook into gevent and swap our pure-python stacks
as well.

Thread locals are "greenlet locals" in gevent so this isn't an issue.

But like Russell I doubt this proposal actually solves the problem.

For instance, thread locals are strictly equivalent to regular variables in
tests because they are single threaded (with a handful of exceptions). But
allowing testing in isolation is a major goal of "removing global state".

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mWG%3Dj-nNoiwRrryjMEk9Vqy5q69dn%3DoOOfWax0vB9ovRg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.