Re: An argument against mark_safe.

[Daniele Procida]

On Wed, Oct 16, 2013, Jonathan Slenders  wrote:

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

I am not sure if you're saying this is a bad thing, but it is unavoidable, 
isn't it? For example I use the Google Maps API, and I don't know of any other 
way to generate the map items dynamically than to build some of the JS for it 
using template tags. Is there a problem doing it like this, and is there a 
better way?

Daniele

-- 
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/20131017080600.1363122391%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ImportError: cannot import name actions

[rok]

Hi everyone,

unfortunately I am not able to reproduce it from a "scratch-point", I am 
sorry.

Also, we are not using gunicorn, just apache+mod_wsgi.

I read somewhere that this could be related to the python path so I checked 
it in dev and production environments, and simply set the same path in dev 
by setting the sys.path=[the same list of paths as in dev] within the 
wsgi.py to try to eliminate this potential cause. Still, the problem 
persisted.

Rok

On Wednesday, October 16, 2013 9:26:33 AM UTC+2, Ivan Kharlamov wrote:
>
> 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-develop...@googlegroups.com . 
> > To post to this group, send email to 
> > django-d...@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/be57e5c2-b687-40f0-9c82-532f42384325%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt

Re: An argument against mark_safe.

[Marc Tamlyn]

Personally I tend to attach data attributes to the wrapping node for the
map/chart at HTML escaped JSON and then read them from an external JS file.
Especially as that js can be fairly complex it's best to keep it outside
the template where it can be compressed.

But we digress. I'm in favour of mark_safe having a name which suggest HTML
as that's what it does. I don't however think it will stop people doing it
wrong. However, I'm not sure if there's an easy way to apply your own
default escape function (instead of HTML escaping) say if you are
outputting a JS or TeX doc and have written an escaper you're happy with.
We may as well make this pluggable.

Marc
On 17 Oct 2013 09:06, "Daniele Procida"  wrote:

> On Wed, Oct 16, 2013, Jonathan Slenders 
> wrote:
>
> >Some people still have javascript in their templates and they use template
> >tags inside their javascript. :(
>
> I am not sure if you're saying this is a bad thing, but it is unavoidable,
> isn't it? For example I use the Google Maps API, and I don't know of any
> other way to generate the map items dynamically than to build some of the
> JS for it using template tags. Is there a problem doing it like this, and
> is there a better way?
>
> Daniele
>
> --
> 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/20131017080600.1363122391%40smtp.modern-world.net
> .
> 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/CAMwjO1GxEKy-%2BM%2Br10joeTsnaoqm4QCojnVj6%2BSKwu2%3DPdJFVw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: An argument against mark_safe.

[Bruno Renié]

On Thu, Oct 17, 2013 at 10:06 AM, Daniele Procida  wrote:
> On Wed, Oct 16, 2013, Jonathan Slenders  wrote:
>
>>Some people still have javascript in their templates and they use template
>>tags inside their javascript. :(
>
> I am not sure if you're saying this is a bad thing, but it is unavoidable, 
> isn't it? For example I use the Google Maps API, and I don't know of any 
> other way to generate the map items dynamically than to build some of the JS 
> for it using template tags. Is there a problem doing it like this, and is 
> there a better way?

I see at least 2 more robust ways:

* Loading map items in another JSON request or as an embedded JSON
string in a hidden  or something. Then your JS code can
simply JSON.parse() the data and no other code generation is required.

* Using data-attributes that can be parsed using completely static JS
code: . You could
imagine storing map items as DOM elements with data-attributes
attached.

Bruno

-- 
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/CAB4BXAjqtoweb0JG%3DpggtRtP_t5_p1nCZZoHDKBL%3DLxyzorYDg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ImportError: cannot import name actions

[Marc Tamlyn]

Can you perhaps try it with a check out of Django and use git bisect to
find the cause? That might give us an indication of how the code base has
changed to break it for you. Without a means of reproduction it is hard for
us to do anything.

Marc
On 17 Oct 2013 09:12, "rok"  wrote:

> Hi everyone,
>
> unfortunately I am not able to reproduce it from a "scratch-point", I am
> sorry.
>
> Also, we are not using gunicorn, just apache+mod_wsgi.
>
> I read somewhere that this could be related to the python path so I
> checked it in dev and production environments, and simply set the same path
> in dev by setting the sys.path=[the same list of paths as in dev] within
> the wsgi.py to try to eliminate this potential cause. Still, the problem
> persisted.
>
> Rok
>
> On Wednesday, October 16, 2013 9:26:33 AM UTC+2, Ivan Kharlamov wrote:
>>
>> 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-develop...@**googlegroups.com.
>> > To post to this group, send email to django-d...@**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 mes

Help related executing system command from django

[Malhar Vora]

Hello,

I am executing a python script from django as described below.

def executeScript(request):
'''
View to execute script from web interface
'''
print "Execute script view called"
basepath =  os.path.dirname(os.path.abspath(__file__))
filepath = basepath + os.path.sep + "script" + os.path.sep +
"dataintegrator.py"
argpath = basepath + os.path.sep + "script" + os.path.sep + "urls.txt"
print "FilePath : " + filepath
print "ArgPath : " + argpath

test = subprocess.call(["python", filepath, argpath])
print "###Result of execution is : " + str(test)
return HttpResponseRedirect("webadmin")

Here in above code, dataintegrator.py is a script that I am executing from
django web. Now code in a script opens a file called "maps.txt" which is
also in same directory as dataintegrator.py. When I execute script from
command line it can read file but execution from web interface gives
exception.

IOError: [Errno 2] No such file or directory: 'maps.txt'

Even the maps.txt file exists in same directory and script runs fine from
command line than what is the problem with web interface. Anyone knows the
solution ?


Regds,
*Malhar Vora*
http://about.me/malhar.vora

-- 
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/CAFA4AP-85pHuCFudKp04QpK5110PV7aAKQ6xxQuC%2BRogJKpU8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Help related executing system command from django

[Jorge Cardoso Leitão]

Hi Malhar.

I suggest you to post your question in the django-users mailing list. This 
mailing list is for the development of Django itself.

Thank you,
Jorge

On Oct 17, 2013, at 11:21 , Malhar Vora  wrote:

> Hello,
> 
> I am executing a python script from django as described below.
> 
> def executeScript(request):
> '''
> View to execute script from web interface
> '''
> print "Execute script view called"
> basepath =  os.path.dirname(os.path.abspath(__file__))
> filepath = basepath + os.path.sep + "script" + os.path.sep + 
> "dataintegrator.py"
> argpath = basepath + os.path.sep + "script" + os.path.sep + "urls.txt"
> print "FilePath : " + filepath
> print "ArgPath : " + argpath
> 
> test = subprocess.call(["python", filepath, argpath])
> print "###Result of execution is : " + str(test)
> return HttpResponseRedirect("webadmin")
> 
> Here in above code, dataintegrator.py is a script that I am executing from 
> django web. Now code in a script opens a file called "maps.txt" which is also 
> in same directory as dataintegrator.py. When I execute script from command 
> line it can read file but execution from web interface gives exception.
> 
> IOError: [Errno 2] No such file or directory: 'maps.txt'
> 
> Even the maps.txt file exists in same directory and script runs fine from 
> command line than what is the problem with web interface. Anyone knows the 
> solution ?
> 
> 
> Regds,
> Malhar Vora
> http://about.me/malhar.vora
> 
> 
> -- 
> 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/CAFA4AP-85pHuCFudKp04QpK5110PV7aAKQ6xxQuC%2BRogJKpU8Q%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/3511D754-451C-47C9-A350-034068565103%40sapo.pt.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Help related executing system command from django

[Daniele Procida]

On Thu, Oct 17, 2013, Jorge Cardoso Leitão  wrote:

>I suggest you to post your question in the django-users mailing list.
>This mailing list is for the development of Django itself.

The django-users list can be found at 
.

The #django IRC channel on IRC (on irc.freenode.net) is also very helpful.

Daniele

-- 
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/20131017103116.1382276699%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Django logo usage terms self-contradiction

[Daniele Procida]

"Additional text may not be added so that it appears to be part of the logo."

 section 3.2:

"A group or event may use a logo that incorporates the Django logo by adding a 
word or picture [...]"

Also, there appears to be no section 3.1 on the latter page.

Daniele

-- 
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/20131017135509.1987695617%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

[Announce] Expected djangoproject.com downtime tomorrow, Oct 18, starting 20:00 UTC

[Jacob Kaplan-Moss]

Hi folks -

We'll be doing some work on djangoproject.com (and associated sub-sites)
tomorrow, starting around 20:00 UTC. Expect some downtime, possibly as long
as an hour or so, starting around then.

During the downtime, as usual, you can find a mirror of Django's
documentation on Read the Docs: http://django.readthedocs.org/en/latest/.

Thanks!

Jacob

-- 
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/CAK8PqJGpj3Jv%2BP0Zqj6u0Q4RuhfYJYniNKk%3DWxjV5mimx0Wn4A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

sensitive_post_parameters

[Michael Manfre]

I just discovered that using @method_decorator(sensitive_post_parameters())
doesn't properly cleanse request.POST for all of the traceback frames.
Specifically, method_decorator's inner bound_func leaks the request because
it is contained in the args2 variable and not named request.

I plan on creating a ticket for this. If this usage is deemed valid, then
it's a pretty serious issue for any site dealing with credit cards and it's
probably a release blocker. If this usage is not valid, then the ticket
will be to update the documentation so that others know not to do that.

Regards,
Michael Manfre

-- 
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/CAGdCwBvDyULgNvcQ6KKOhaeuxiO6_%2Bu3JtWYy7brDakJDr5UNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Luciano Pacheco]

A few cents...

First, a  project wide settings to control this behaviour would be complex
with pluggable apps. Some apps might expect global valodation enabled, but
some might expect it disabled.

We should have model.save validating by default and have a flag to turn it
off. I think it's reasonable to assume that by default we want our data to
be consistent.

Regards,

Luciano Pacheco
On 17/10/2013 10:47 AM, "Cal Leeming [Simplicity Media Ltd]" <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> 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 

Re: Possible idea for removing global state in Django.

[Shai Berger]

On Thursday 17 October 2013 08:34:48 Aymeric Augustin wrote:
> 
> 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".

If I understand correctly, what Jonathan is suggesting is not your garden-
variety thread-local variables, but what Common Lisp calls "dynamically scoped 
variables" -- you could call them "call-stack-local" or something like that. 
In Python terms, every change to the values of such variables would be done in 
the __enter__() of a context manager, and undone (that is, old value restored) 
in the __exit__(). I think such variables are a great idea, and would indeed 
help a lot with all the problems associated with global state. In terms of 
software engineering, they are a lot like exceptions: A channel of 
communications between functions on different levels of the call stack, that 
does not require explicit acknowledgement on every level, and yet does not 
completely break locality.

However, I don't think such variables can be used in a reliable and elegant 
manner without language-level support, and sadly, Python does not support 
them. Attempts I've made to get the functionality using context managers ended 
with awkward APIs for either setting values, getting values, or both; as a 
trivial example, Jonathan's suggestion of the context manager being returned 
by django_project.activate() is of such low granularity, that it is almost 
equivalent to regular globals.

If a reasonable API for this can be defined, I'd be all for it. I suspect 
that's a non-trivial "if".

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/3631394.jhQ5yuEHHh%40deblack.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django logo usage terms self-contradiction

[Russell Keith-Magee]

Hi Daniele,

Thanks for the heads up. The first piece of text you've indicated predates
the second, so it needed to be updated. I've just made the change.

As for there being no Section 3.1 -- I'm not sure what you're referring to
here. I can see a Section 3 that contains 2 subsections, numbered 1 and 2;
section 3.1 has 6 subclauses 3.1.1-3.1.6.

Yours,
Russ Magee %-)


On Thu, Oct 17, 2013 at 9:55 PM, Daniele Procida  wrote:

> 
>
> "Additional text may not be added so that it appears to be part of the
> logo."
>
>  section 3.2:
>
> "A group or event may use a logo that incorporates the Django logo by
> adding a word or picture [...]"
>
> Also, there appears to be no section 3.1 on the latter page.
>
> Daniele
>
> --
> 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/20131017135509.1987695617%40smtp.modern-world.net
> .
> 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/CAJxq84_OdhQKZw0-dCAQRN5VMRGjUWyPkyfyh_0ESe4JofuUKg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django logo usage terms self-contradiction

[Daniele Procida]

On Fri, Oct 18, 2013, Russell Keith-Magee  wrote:

>Thanks for the heads up. The first piece of text you've indicated predates
>the second, so it needed to be updated. I've just made the change.
>
>As for there being no Section 3.1 -- I'm not sure what you're referring to
>here. I can see a Section 3 that contains 2 subsections, numbered 1 and 2;
>section 3.1 has 6 subclauses 3.1.1-3.1.6.

That's changed! 

Earlier today there was no list marker "1." for the  "You may incorporate 
the Django name into the name of any group or event, provided that:"

Maybe the re-rendering of the page restored it.

Daniele

-- 
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/20131017230651.851306701%40smtp.modern-world.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: sensitive_post_parameters

[Tim Graham]

Posting some of the discussion from IRC:

I've done some recent work with sensitive_post_parameters:

https://github.com/django/django/commit/2daada800f8e28cc1ba664b3008efaefab8fb570

The general lesson I learned was blacklisting isn't a very comprehensive 
approach and there are definitely ways you can inadvertently leak data. The 
docs should probably warn against insecure error collection (like email), 
even if using the sensitive decorators.

Patches to improve things would be welcome. I'm hesitant to treat it as a 
security issue/release blocker, but we can probably backport it to 1.6 at 
least.

On Thursday, October 17, 2013 3:50:21 PM UTC-4, Michael Manfre wrote:
>
> I just discovered that using 
> @method_decorator(sensitive_post_parameters()) doesn't properly cleanse 
> request.POST for all of the traceback frames. Specifically, 
> method_decorator's inner bound_func leaks the request because it is 
> contained in the args2 variable and not named request.
>
> I plan on creating a ticket for this. If this usage is deemed valid, then 
> it's a pretty serious issue for any site dealing with credit cards and it's 
> probably a release blocker. If this usage is not valid, then the ticket 
> will be to update the documentation so that others know not to do that.
>
> Regards,
> Michael Manfre
>

-- 
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/8433c3a9-cafe-48cf-ab95-27e48cd1e4c1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Karen Tracey]

On Wed, Oct 16, 2013 at 7:03 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

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


Wasn't there also concern for double validation performed during form clean
and then model instance save?

-- 
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/CACS9rad0m22maOKrpn-T6vU7ZC2Y%3DK3V9P9%3DP_5Qf%3DEt0k4yTA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[Anssi Kääriäinen]

On Friday, October 18, 2013 5:28:21 AM UTC+3, Karen Tracey wrote:
>
>
> On Wed, Oct 16, 2013 at 7:03 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>>> 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.
>>  
>>
>
>
> Wasn't there also concern for double validation performed during form 
> clean and then model instance save?
>

Another problem is performance - some database validations aren't cheap. 
Uniqueness checks and foreign key checks do generate database queries, and 
both of these are already validated in the DB (well, in any real DB). In 
many realistic cases model.save() could get multiple times more expensive 
than what it is now.

In addition model validation on save() still doesn't give you any guarantee 
that your data in the DB is actually correct. Using .update() will still 
pass any validation. And, for any validation that checks data from 
referenced models, it is going to be very likely that concurrent 
transactions will lead to invalid data in the DB. Getting plain referential 
integrity right under concurrency is surprisingly hard, and getting more 
advanced constraints right is still harder.

If you want your data consistent you want your validations done in the DB. 
So, personally I am more interested in trying to have more constraints 
automatically created in the DB. Of course, not all types of validation are 
easy to do in SQL, for example converting random python validations to DB 
triggers is pretty much impossible. But there are also validations that 
would be straightforward to do (value in choices for example).

I guess I am -0 on automatic model validation on .save(). In any case I 
would make the default mode model._meta flag so that you could choose the 
default per model.

 - 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/17e77e96-f977-4000-aaf2-1ee11fb49f92%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.