Re: Auto-import support for models and other objects in shell

[Russell Keith-Magee]

I'm in complete agreement with Alex. -1 from me. Explicit is better
than implicit, and to my mind, hiding imports just complicates the
learning curve associated with Django's package tree.

If you *really* want this, there are hooks into ipython et al that can
do this; I don't see it as something appropriate for Django itself.

Yours,
Russ Magee %-)

On Wed, Aug 29, 2012 at 5:42 AM, Alex Gaynor  wrote:
>
>
> On Tue, Aug 28, 2012 at 2:40 PM, Phill Tornroth 
> wrote:
>>
>> 'Ello.
>>
>> I'm gauging support for a tiny new feature, or at least a refactoring of
>> an internal API that will allow the feature to be developed without code
>> duplication. I'd like to stop typing import statements for all of my models
>> and other common stuff into my django shell. In fact, I'd love for all of us
>> to stop typing those import statements! I tossed up the following pull
>> requests as an example for how this might look:
>>
>> https://github.com/django/django/pull/303
>>
>> This is effectively a subset of the functionality that shell_plus [1]
>> appears to provide. The problem that I have with building my own, or with
>> using shell_plus is that the shell command doesn't allow this change to be
>> built without effectively copying the entire internal implementation of the
>> shell command. New features added to, or issues fixed in shell will have to
>> be copied over to shell_plus, or our homegrown solutions which is
>> unfortunate. So at the very least it seems reasonable to provide something
>> like the get_initial_shell_locals method I added in my pull request, which
>> makes this feature easy enough to add without duplication.
>>
>> In fact, that's where my thinking started but I also don't see a downside
>> to providing this functionality in core either. I don't think it's
>> usefulness is particularly questionable or niche, as the existence of
>> shell_plus seems evidence of.
>>
>> I haven't opened a ticket because the contribution docs suggest gauging
>> consensus, first. So I think these are the two potential (not mutually
>> exclusive) changes worth gauging support for:
>>
>> 1. An overridable method (or some other internal API change?) to make it
>> possible to implement this functionality without copying the entire shell
>> implementation.
>> 2. A default implementation for said method that supports auto-importing
>> useful objects into the shell scope.
>>
>>
>> Curious to hear what people think. Of course, please let me know if I'm
>> going about this the wrong way.
>>
>> Thanks!
>> Phill
>>
>> [1]:
>> https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/gcpo73Sk5aMJ.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>
>
> I'm pretty strongly -1 on this. I understand it can be a real convenience,
> but this is precisely the type of feature that makes things way more
> confusing for anyone who's new to a project, "Why are the things magically
> available here?". I realize this is "just" the shell, but I've been very
> critical of other frameworks for making things magically available, and I'm
> going to hold us to the same standard.
>
> Alex
>
> --
> "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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: M2M with to_fields (ticket #18823)

[Russell Keith-Magee]

Hi Peter,

Thanks for that; I've just marked the ticket as a release blocker, so
at the very worst, this should be corrected for the 1.5 release.

Yours,
Russ Magee %-)

On Tue, Aug 28, 2012 at 11:56 PM, peter  wrote:
> The wrong rows being deleted is a possibility. Here's an example:
>
> class Through(models.Model):
> two = models.ForeignKey('Model2', to_field='spot')
> one = models.ForeignKey('Model1')
>
> class Model1(models.Model):
> name = models.CharField(max_length=100)
>
> class Model2(models.Model):
> spot = models.IntegerField(unique=True)
> ones = models.ManyToManyField(Model1, through=Through)
>
> # Create objects and relations
> m = Model1(name='test')
> m2 = Model2(spot=2, pk=1)
> m3 = Model2(spot=1, pk=2)
> m.save()
> m2.save()
> m3.save()
> Through(two=m2, one=m).save()
> Through(two=m3, one=m).save()
>
> # Both have ones
> m2.ones.all()
> m3.ones.all()
>
> m2.ones.clear()
>
> # Still has ones, didn't get deleted when it should have
> m2.ones.all()
>
> # This got deleted instead
> m3.ones.all()
>
> It's not exactly a real world example though i think it demonstrates that
> data loss is a possibility.
>
> Monday, August 27, 2012 5:33:03 PM UTC-7, Russell Keith-Magee wrote:
>>
>> On Tue, Aug 28, 2012 at 3:11 AM, peter  wrote:
>> > I opened this ticket (https://code.djangoproject.com/ticket/18823) on
>> > the
>> > Trac but thought i'd bring it up here to increase the likelihood of it
>> > getting noticed. In short things don't quite work right when you have a
>> > m2m
>> > field that uses a through model that uses a to_field for it's foreign
>> > key.
>> > If someone wouldn't mind reviewing the patch and giving me some
>> > feedback,
>> > I'd like to help get this issue fixed.
>> >
>> > Assuming a fix in some form is accepted, I was also wondering if this
>> > bug
>> > fix would be considered important enough to backport to bugfix branches?
>> > Or
>> > will we need to wait for the next major release to get the fix in an
>> > official release.
>>
>> Generally speaking, we don't backport bug fixes unless they relate to:
>>
>>  * Security issues
>>
>>  * Major problems with newly added features
>>
>>  * Problems with the potential to cause catastrophic data los -- i.e.,
>> accidentally deleting/dropping data, or deleting/dropping the wrong
>> data.
>>
>> A rule of thumb: If we'd discovered this feature the day before we cut
>> a major release, would we have held back the release?
>>
>> In this case, it's not a security issue, and the code has had this
>> problem for several years; we certainly aim for being bug free, but
>> we've evidently survived with this bug for some time without any
>> serious problems. However, you *might* be able to make the case that
>> catastrophic data loss is possible. From an initial analysis, it seems
>> like it might be possible to accidentally delete the wrong through
>> model. If you can provide a clear example of a case where this would
>> happen, then yes, a backport is likely.
>>
>> Yours,
>> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/hzKJaotTKkQJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Auto-import support for models and other objects in shell

[Carl Meyer]

Hi Phill,

On 08/28/2012 03:51 PM, Phill Tornroth wrote:
> 2. Are you also -1 on making it easier for projects like shell_plus to
> add locals to the shell? What's happening right now is pretty
> unfortunate. I can only see upside in an adjustment to the internal API
> that doesn't make this kind of duplication necessary.

I think this is a practically useful feature, but it's pretty far afield
for a web framework, IMO [1]. Ideally it could be handled by convenience
shells such as IPython without needing to add anything new to "manage.py
shell". I know that in older versions of IPython auto-imports could be
easily done with an ipy_user_conf.py file in the same directory as
manage.py; since "manage.py shell" runs IPython if installed, that
solves the problem. I think the customization system has changed in
newer IPython versions and I haven't looked into how to do it now - but
that still seems to me like basically the right approach.

Carl



  [1] Of course, the same could be said for "manage.py shell" itself,
which, in Django 1.4 at least, is little more than a shortcut for
setting DJANGO_SETTINGS_MODULE and running a python shell. I'd love to
see "manage.py shell" disappear entirely from Django someday.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Auto-import support for models and other objects in shell

[Phill Tornroth]

Totally fair, couple of things:

1. For backward compatibility and the confusion you mentioned, I'd suggest 
this be not enabled by default. Let people who want the feature (the people 
who download shell_plus for instance) enable it. My pull request leaves it 
totally off by default, retaining current behavior. In my opinion this 
removes the 'magically available' argument. The classes would be as 
magically available as context vars in templates are.

2. Are you also -1 on making it easier for projects like shell_plus to add 
locals to the shell? What's happening right now is pretty unfortunate. I 
can only see upside in an adjustment to the internal API that doesn't make 
this kind of duplication necessary.

Thanks for reading.
Phill

On Tuesday, August 28, 2012 2:42:43 PM UTC-7, Alex_Gaynor wrote:
>
>
>
> On Tue, Aug 28, 2012 at 2:40 PM, Phill Tornroth 
>  > wrote:
>
>> 'Ello.
>>
>> I'm gauging support for a tiny new feature, or at least a refactoring of 
>> an internal API that will allow the feature to be developed without code 
>> duplication. I'd like to stop typing import statements for all of my models 
>> and other common stuff into my django shell. In fact, I'd love for all of 
>> us to stop typing those import statements! I tossed up the following pull 
>> requests as an example for how this might look:
>>
>> https://github.com/django/django/pull/303
>>
>> This is effectively a subset of the functionality that shell_plus [1] 
>> appears to provide. The problem that I have with building my own, or with 
>> using shell_plus is that the shell command doesn't allow this change to be 
>> built without effectively copying the entire internal implementation of the 
>> shell command. New features added to, or issues fixed in shell will have to 
>> be copied over to shell_plus, or our homegrown solutions which is 
>> unfortunate. So at the very least it seems reasonable to provide something 
>> like the get_initial_shell_locals method I added in my pull request, 
>> which makes this feature easy enough to add without duplication.
>>
>> In fact, that's where my thinking started but I also don't see a downside 
>> to providing this functionality in core either. I don't think it's 
>> usefulness is particularly questionable or niche, as the existence of 
>> shell_plus seems evidence of.
>>
>> I haven't opened a ticket because the contribution docs suggest gauging 
>> consensus, first. So I think these are the two potential (not mutually 
>> exclusive) changes worth gauging support for:
>>
>> 1. An overridable method (or some other internal API change?) to make it 
>> possible to implement this functionality without copying the entire shell 
>> implementation.
>> 2. A default implementation for said method that supports auto-importing 
>> useful objects into the shell scope.
>>
>>
>> Curious to hear what people think. Of course, please let me know if I'm 
>> going about this the wrong way.
>>
>> Thanks!
>> Phill
>>
>> [1]: 
>> https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py
>>  
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-developers/-/gcpo73Sk5aMJ.
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> I'm pretty strongly -1 on this. I understand it can be a real convenience, 
> but this is precisely the type of feature that makes things way more 
> confusing for anyone who's new to a project, "Why are the things magically 
> available here?". I realize this is "just" the shell, but I've been very 
> critical of other frameworks for making things magically available, and I'm 
> going to hold us to the same standard.
>
> Alex
>
> -- 
> "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
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/a4TV7rbfzsMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Auto-import support for models and other objects in shell

[Alex Gaynor]

On Tue, Aug 28, 2012 at 2:40 PM, Phill Tornroth wrote:

> 'Ello.
>
> I'm gauging support for a tiny new feature, or at least a refactoring of
> an internal API that will allow the feature to be developed without code
> duplication. I'd like to stop typing import statements for all of my models
> and other common stuff into my django shell. In fact, I'd love for all of
> us to stop typing those import statements! I tossed up the following pull
> requests as an example for how this might look:
>
> https://github.com/django/django/pull/303
>
> This is effectively a subset of the functionality that shell_plus [1]
> appears to provide. The problem that I have with building my own, or with
> using shell_plus is that the shell command doesn't allow this change to be
> built without effectively copying the entire internal implementation of the
> shell command. New features added to, or issues fixed in shell will have to
> be copied over to shell_plus, or our homegrown solutions which is
> unfortunate. So at the very least it seems reasonable to provide something
> like the get_initial_shell_locals method I added in my pull request,
> which makes this feature easy enough to add without duplication.
>
> In fact, that's where my thinking started but I also don't see a downside
> to providing this functionality in core either. I don't think it's
> usefulness is particularly questionable or niche, as the existence of
> shell_plus seems evidence of.
>
> I haven't opened a ticket because the contribution docs suggest gauging
> consensus, first. So I think these are the two potential (not mutually
> exclusive) changes worth gauging support for:
>
> 1. An overridable method (or some other internal API change?) to make it
> possible to implement this functionality without copying the entire shell
> implementation.
> 2. A default implementation for said method that supports auto-importing
> useful objects into the shell scope.
>
>
> Curious to hear what people think. Of course, please let me know if I'm
> going about this the wrong way.
>
> Thanks!
> Phill
>
> [1]:
> https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/gcpo73Sk5aMJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

I'm pretty strongly -1 on this. I understand it can be a real convenience,
but this is precisely the type of feature that makes things way more
confusing for anyone who's new to a project, "Why are the things magically
available here?". I realize this is "just" the shell, but I've been very
critical of other frameworks for making things magically available, and I'm
going to hold us to the same standard.

Alex

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Auto-import support for models and other objects in shell

[Phill Tornroth]

'Ello.

I'm gauging support for a tiny new feature, or at least a refactoring of an 
internal API that will allow the feature to be developed without code 
duplication. I'd like to stop typing import statements for all of my models 
and other common stuff into my django shell. In fact, I'd love for all of 
us to stop typing those import statements! I tossed up the following pull 
requests as an example for how this might look:

https://github.com/django/django/pull/303

This is effectively a subset of the functionality that shell_plus [1] 
appears to provide. The problem that I have with building my own, or with 
using shell_plus is that the shell command doesn't allow this change to be 
built without effectively copying the entire internal implementation of the 
shell command. New features added to, or issues fixed in shell will have to 
be copied over to shell_plus, or our homegrown solutions which is 
unfortunate. So at the very least it seems reasonable to provide something 
like the get_initial_shell_locals method I added in my pull request, which 
makes this feature easy enough to add without duplication.

In fact, that's where my thinking started but I also don't see a downside 
to providing this functionality in core either. I don't think it's 
usefulness is particularly questionable or niche, as the existence of 
shell_plus seems evidence of.

I haven't opened a ticket because the contribution docs suggest gauging 
consensus, first. So I think these are the two potential (not mutually 
exclusive) changes worth gauging support for:

1. An overridable method (or some other internal API change?) to make it 
possible to implement this functionality without copying the entire shell 
implementation.
2. A default implementation for said method that supports auto-importing 
useful objects into the shell scope.


Curious to hear what people think. Of course, please let me know if I'm 
going about this the wrong way.

Thanks!
Phill

[1]: 
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/shell_plus.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/gcpo73Sk5aMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Tabular inline improvement

[Dylan Klomparens]

Hello all,

I have a suggestion for improving the tabular inline view of the admin site 
(contained in /contrib/admin/templates/admin/edit_inline/tabular.html). I recently 
overloaded this template for my own purposes, and am wondering if the 
Django community would find my changes useful. If so, I suppose I'll polish 
the code a bit more and submit a patch.

Currently, the tabular inline view looks like this (below). Please note 
that in this picture the fields are marked as read only, but the option to 
edit them in-place is provided by Django.


I modified the template to look like this:


My initial thoughts for the improvement are:

   - If the first field in the row is *read only* then:
  - Provide a link to the relevant object.
  - Compact the height of each row by not displaying the object's 
  string representation (i.e. the __unicode__ function).
  - No link would be provided if the user does not have permission to 
  change the object.
   - Otherwise, if the first field in the row is *editable* then:
  - Provide a link to the relevant object by keeping the object's 
  string representation (as displayed in the first picture, above).
   
Thoughts?

If I get a +1 from some of the core devs on this then I'll start working on 
a patch.

-- Dylan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/hrBW1wUeIYkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: M2M with to_fields (ticket #18823)

[peter]

The wrong rows being deleted is a possibility. Here's an example:

class Through(models.Model):
two = models.ForeignKey('Model2', to_field='spot')
one = models.ForeignKey('Model1')

class Model1(models.Model):
name = models.CharField(max_length=100)

class Model2(models.Model):
spot = models.IntegerField(unique=True)
ones = models.ManyToManyField(Model1, through=Through)

# Create objects and relations
m = Model1(name='test')
m2 = Model2(spot=2, pk=1)
m3 = Model2(spot=1, pk=2)
m.save()
m2.save()
m3.save()
Through(two=m2, one=m).save()
Through(two=m3, one=m).save()

# Both have ones
m2.ones.all()
m3.ones.all()

m2.ones.clear()

# Still has ones, didn't get deleted when it should have
m2.ones.all()

# This got deleted instead
m3.ones.all()

It's not exactly a real world example though i think it demonstrates that 
data loss is a possibility.

Monday, August 27, 2012 5:33:03 PM UTC-7, Russell Keith-Magee wrote:

> On Tue, Aug 28, 2012 at 3:11 AM, peter  
> wrote: 
> > I opened this ticket (https://code.djangoproject.com/ticket/18823) on 
> the 
> > Trac but thought i'd bring it up here to increase the likelihood of it 
> > getting noticed. In short things don't quite work right when you have a 
> m2m 
> > field that uses a through model that uses a to_field for it's foreign 
> key. 
> > If someone wouldn't mind reviewing the patch and giving me some 
> feedback, 
> > I'd like to help get this issue fixed. 
> > 
> > Assuming a fix in some form is accepted, I was also wondering if this 
> bug 
> > fix would be considered important enough to backport to bugfix branches? 
> Or 
> > will we need to wait for the next major release to get the fix in an 
> > official release. 
>
> Generally speaking, we don't backport bug fixes unless they relate to: 
>
>  * Security issues 
>
>  * Major problems with newly added features 
>
>  * Problems with the potential to cause catastrophic data los -- i.e., 
> accidentally deleting/dropping data, or deleting/dropping the wrong 
> data. 
>
> A rule of thumb: If we'd discovered this feature the day before we cut 
> a major release, would we have held back the release? 
>
> In this case, it's not a security issue, and the code has had this 
> problem for several years; we certainly aim for being bug free, but 
> we've evidently survived with this bug for some time without any 
> serious problems. However, you *might* be able to make the case that 
> catastrophic data loss is possible. From an initial analysis, it seems 
> like it might be possible to accidentally delete the wrong through 
> model. If you can provide a clear example of a case where this would 
> happen, then yes, a backport is likely. 
>
> Yours, 
> Russ Magee %-) 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/hzKJaotTKkQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Moving forward with Serialization.

[Tom Christie]

Hi all,

  During Piotr's GSOC addressing customizable serialization I've been 
continued to work on my own implementation.
I've now got what feels to me to be a natural conclusion of the design, 
which is the 'forms' branch of the 
'django-serializers'project.

There's still a few small bits and pieces that need filling in, but it's 
pretty much there,
and I believe the project essentially meets the requirements of a more 
customizable serialization API.

I won't go into the full documentation here (refer to the project itself if 
you're interested), but in summary it gives you:

* A declarative serialization API with Serializer/ModelSerializer classes 
that mirror the existing Form/ModelForm API.
* A backwards compatible FixtureSerializer class.
* Support for nested relationships, pk relationships, natural key 
relationships, and custom relationships such as hyperlinking.
* Validation for deserialization of objects, similar to Form validation.
* Explicitly decouples the structural concerns of serialization from the 
encoding/decoding concerns.
* Passing Django's existing fixture serialization tests.
* Fairly trivial to port into Django while keeping backwards compatibility 
with existing serialization API.

What I particularly like about the approach is how it mirrors the existing 
Forms API, and I think it'd go a long way to making Django a more useable 
framework for authors of Web APIs.  As an example, here's what it looks 
like when using django-serializers to write API 
views
.

At this point what I'm looking for is some feedback:

* Would it be worth me trying to push towards getting this into core.
* Are there any fundamental issues with the API, or use cases it clearly 
doesn't address.
* Any suggested next steps, or things that would need to be 
addressed/clarified before it could considered it for core.

It's probably also worth noting that I'm now planning on using the project 
inside my personal project, django-rest-framework, in case that's relevant 
to the discussion.

Thoughts?

  Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/3ypJSF7nN8oJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Invalid deleted forms in formsets break form data access

[Iho]

The worst in this situation is that we have 2012 3Q in the yard but the 
issue still open :(

Четвер, 12 серпня 2010 р. 10:32:32 UTC+3 користувач Tomi Pieviläinen 
написав:
>
> I first approached the users-list to find out if I was simply doing 
> something wrong, but seems like there's no (obvious) mistake. 
>
> In a formset with can_delete, fs.is_valid() passes even if some of the 
> deleted forms are invalid. However fs.cleaned_data tries to access 
> every form, including the deleted forms, and causes an exception when 
> every form does not have cleaned_data. 
>
> Since fixing http://code.djangoproject.com/ticket/11801 the 
> deleted_forms is available even for invalid forms, but this does not 
> seem to help in anyway. Trying to remove the deleted forms from 
> fs.forms causes an array index out of bounds when iterating over 
> fs.cleaned_data. So it seems like there's no reasonable way to handle 
> the validated data in a formset if there is an invalid deleted form. 
> This is really surprising after is_valid has already passed. 
>
> This problem is encountered when a user starts modifying a form but 
> decides that the whole set of data should be deleted anyway. Requiring 
> that the form should be fixed before deletion is possible seems like 
> an unreasonable request, after all the data will be just deleted after 
> it validates (this is the current case in admin). 
>
> I'm not sure if this is an intended consequence (a documentation bug), 
> if this case should be added to an existing ticket (http:// 
> code.djangoproject.com/ticket/10828), an older ticket reopened (such 
> as http://code.djangoproject.com/ticket/9587) or a new ticket should 
> be made.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/W_ufC7bVZI8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.