Re: #9344 and policy for small bug reports
On Jan 23, 5:14 pm, Russell Keith-Magee wrote: > On Fri, Jan 23, 2009 at 2:38 PM, Julien Phalip wrote: > > > Now, I know that this is sort of an edge case, and I also know that > > there are more important and more urgent matters at this moment. But > > I'd be keen to hear what is the official (or tacit) policy for that > > kind of small bug reports. There probably are a few other tickets in > > that situation (#9404 is another example). So, what is the best way to > > go for people interested in having them checked in? Is it simply by > > bringing them up on this mailing list from time to time? If so, then I > > can try again after 1.1 lands. > > Hi Julien, > > Unfortunately, there's no simple answer to this question. > > The short answer is that it is all about timing and opportunity. > > A polite, well-timed message to the mailing list is certainly one way > to get attention. Keep an eye on the grand schedule. If you make noise > when the core devs are under the hammer trying to hit a feature > deadline or manage a planning phase, you're probably going to get > ignored. However, raising the ticket when the core devs are paying > attention to bugs - just before a bug fixing sprint, or in the leadup > to a beta release for example - is likely to get some traction. > > Gentle IRC reminders can also work - again, strategically timed > (during a bug sprint would be a very good time, for example). > > Another way to get traction is to pull related items together. When I > jump into the code to fix a bug in an area I haven't touched for a > while, it can take a few minutes to refresh my memory on exactly how > things work. If you collect minor bugs together into similarly themed > groups, you make an attractive target for us core devs (who are, after > all, exceedingly lazy and like easy jobs much more than hard jobs :-) > > I wish I could give you a concrete answer (ask by email, written in > sanskrit, between 1 and 1:10 pm UTC on Tuesday afternoons :-) but like > all things open source, it isn't that simple. > > Yours, > Russ Magee %-) Thank you Russell for your clear explanation. In fact, I would copy/ paste your reply right into the Django documentation (http:// docs.djangoproject.com/en/dev/internals/contributing/#id1). Those tips are very useful to know! Julien --~--~-~--~~~---~--~~ 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: ManyToManyField in both models/forms
On Jan 23, 3:17 am, Malcolm Tredinnick wrote: > Addressing this only in the admin would be short-sighted, however. A for > field that new how to handle reverse relations would be the first step > and then allowing the admin to use that is the second one. > Maybe better approuch is in model's meta? It will give forms a chance to do this fancy thing. And it is a kind of logical, since model really has such relation. --~--~-~--~~~---~--~~ 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: #9344 and policy for small bug reports
On Jan 23, 6:42 pm, Karen Tracey wrote: > On Fri, Jan 23, 2009 at 12:38 AM, Julien Phalip wrote: > > > Hi, > > > I just wanted to draw your attention to what appears to be a bug in > > Django: the 'tell()' proxy is missing from the Windows-specific > > implementation of TemporaryFile. This causes Django to crash when > > manipulating the uploaded file with PIL, for example. Ticket #9344 > > contains a patch to fix that. > > I probably looked at that ticket initially, at least briefly. Here's a peek > into what likely went on in my head: > > - I should look at that...though I don't know the code involved...nor much > about PIL...still, it's Windows-specific, I've got Windows boxes to test on, > many (most...all?) other committers don't. > - Hmmcrash when manipulating uploaded file with PIL...do I know offhand > how to recreate that...nodo I want to learn enough about PIL to dream up > how to recreate it...not really. > - Maybe the patch has a test? Oh, there are 2 patches...I wonder why? > They're identical...wha? Oh, the first had a spacing error. But regardless, > no test. > - Should there be a test? Is this something that can't be tested? Is that > why no test was provided? Is it blindingly obvious to anyone who knows the > first thing about PIL how to recreate this problem and that's why no > specifics on how to recreate were included? Dunno...this is too hard, let's > find something easier to look at. > > At this point I really should have noted in the ticket what stopped me from > doing anything with it, but I didn't. I'm bad that way, particularly when I > get to a point of thinking that maybe it's my own lack of knowledge that's > the problem. > > So, what that ticket was lacking for me to look at it more closely was > specific instructions as to how to recreate the problem so I could verify > the fix. Even better, a test integrated into the test suite, then it's > clear to anyone looking later on what exact problem was fixed, and there is > built-in protection against it breaking again. If it's not feasible for > some reason to add a test to the test suite then a note indicating why no > test is possible would help. > > Now, the fix may be trivial (and I'll agree it looks trivial), but I'm not > going to check in anything without testing it. Been there, done that, broke > things, try real hard not to do it any more. So I want to be able to see > the problem myself before the fix and verify the problem is gone after the > fix. > > > Now, I know that this is sort of an edge case, and I also know that > > there are more important and more urgent matters at this moment. But > > I'd be keen to hear what is the official (or tacit) policy for that > > kind of small bug reports. There probably are a few other tickets in > > that situation (#9404 is another example). So, what is the best way to > > go for people interested in having them checked in? Is it simply by > > bringing them up on this mailing list from time to time? If so, then I > > can try again after 1.1 lands. > > Best way to make sure "small" tickets do not get hung up on the way to > checkin is to make them dead easy, even for someone who may not be > intimately familiar with that area of the code, to understand the problem > and verify the fix. Include tests integrated into the Django test suite that > fail before the fix and pass afterward. If integrated tests aren't > possible, explain why the fix should be checked in even without tests, and > include manual recreation instructions so the person who is considering the > fix knows how to test it manually. > > Karen Thank you Karen for this detailed answer. Your reasoning regarding this ticket does make a lot of sense. I totally agree with you that tests are highly important and that this ticket is lacking useful information for whoever is not familiar with that area of the code. If I recall, the reason I hadn't written tests for the patch was because of the way #7769 had been checked in shortly before 1.0's release. I had thought that, like #7769, the patch was "trivial" enough for not including tests. But again, as you said, the ticket was lacking information and I should have at least put a link to #7769 in the description. I've just done that. I'll think about writing tests but it seems a bit overkill in this case for something which looks like a small oversight. Thank you, Julien http://code.djangoproject.com/ticket/7769 --~--~-~--~~~---~--~~ 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: Proposal: Make filters in admin persistent (#6903)
On Fri, Nov 14, 2008 at 2:28 PM, Jonas Pfeil wrote: > > Just to be clear we are talking about the same thing: With "persistent > filters" I just mean "going back to the _filtered_ change list after > editing an item". I don't think it makes sense to make them any more > persistent :) Clicking on the link to the change list on the admin > home page should give a fresh start. > > On Nov 14, 2:15 am, Malcolm Tredinnick > wrote: >> Persistent filters makes sense; we should do that. But in the URL if at >> all possible, since it's best practice. > > The change list should really have an URL that includes the filters. > It's a different resource after all. I don't know if the "passing URLs > to a friend" argument is really fitting on the URL of the edit view of > an item though. If we use a from_url GET parameter that would take my > colleague back to _my_ filtered change list. I don't know if this > makes sense, but doesn't really hurt I suppose. Except that it may, > unintentionally, leak the information you searched for to another > person. If we don't want this we could put the information in the > session and use a hash. > > So maybe it's best to use GET parameters as before for the change > list, but store the from_url in the session under a hash that we set > as a GET parameter for the editing process. Just using the session > wouldn't cut it, as we need to track multiple edit actions in > parallel. > > Cheers, > I've updated the existing patch created by slonopotamus for this ticket and intend to working on it hopefully making it worth considering for inclussion. I haven't, so far, changed anything fundamental, and wanted to ask for advice and opinions about the patch and in regard to what has been already discussed in this thread. First, I've found that the concern about the filtered changelist views in the admin app being addresssable resources only by using the query string are already covered by the current implementation so that part isn't something that needs to be solved ((am I wrong about this?) I've listed below a few notes about the patch, some of them with my questions attached: Currently, it: * Gets the URL where the the user should be taken back after the CRUD operation from the Referer HTTP request header, Is this a valid approach? Or should Jonas above ideas about storing it in the session be implemented instead? * It passes that URL around from view to view by using an query string value until the time to use it comes, it does so even when a POST request is sent (when editing or creating a model instance). Are we ok with this? * (Related to the previous item) The variable name used was 'admin_change_return_to', I've changed it to 'return_to'. Do we need to obfuscate somehow it to make it less prone to clash with other vars? * It uses the quote function from of urllib. Should django.contrib.admin.util.quote or django.util.http.urlquote be used instead? Thanks for any feedback. -- Ramiro Morales --~--~-~--~~~---~--~~ 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: pychecker catches IndexError exception while importing /django/db/models/base.py
I think I might be able to spot where the problem is. Try running
pychecker on your app folder, rather than models.py.
Let's assume your app is called myapp, so you have a directory
structure something like this:
myapp/
-- __init__.py
-- models.py
-- views.py
-- tests.py
(et cetera)
If pychecker were doing 'import myapp', then the models module would
be accessible from 'myapp.models'. Therefore, models_module's __name__
attribute would be 'myapp.models', and the code would run fine;
'myapp.models'.split('.') would return ['myapp', 'models'], and the
[-2] index of that list would be 'myapp'.
However, because you're running pychecker directly on the models.py
file, its __name__ attribute is just 'models', which raises an error
in the Django code because 'models'.split('.') returns ['models'] --
this has no [-2] index, hence the exception.
Just try running pychecker on the 'myapp/' folder (if possible), and
see if that fixes the problem.
On Jan 22, 10:22 pm, ivan wrote:
> Hi all,
>
> I'm attempting to run pychecker on my django code (an application's
> models.py file) and get the following output:
>
> $ pychecker models.py
> Processing models...
> Caught exception importing module models:
> File "/var/lib/python-support/python2.5/pychecker/checker.py",
> line 619, in setupMainCode()
> File "models.py", line 538, in ()
> File "/usr/lib/python2.5/site-packages/django/db/models/base.py",
> line 51, in __new__()
> IndexError: list index out of range
>
> Warnings...
>
> models:1: NOT PROCESSED UNABLE TO IMPORT
>
> My django version is '1.0.2 final'.
>
> The IndexError happens on the final line of code extract below:
>
> # Figure out the app_label by looking one level up.
> # For 'django.contrib.sites.models', this would be 'sites'.
> model_module = sys.modules[new_class.__module__]
> kwargs = {"app_label": model_module.__name__.split('.')[-2]}
>
> I added a 'print model_module.__name__' above this line and I get the
> following output before the exception:
> django.contrib.contenttypes.models
> django.contrib.auth.models
> django.contrib.auth.models
> django.contrib.auth.models
> django.contrib.auth.models
> models
>
> Not sure if the last models that triggers the exception is the models
> file I ran pychecker on or another file? I have all my django env
> variables set up correctly and can do runserver, dbshell ,etc.
>
> Any ideas as to why pychecker on my models file would throw this
> exception in the base django models file?
>
> thanks,
> ivan.
--~--~-~--~~~---~--~~
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: Model-validation: call for discussions
I should be around during the weekend so I will give it a try as well...
Honza Král
E-Mail: honza.k...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
On Fri, Jan 23, 2009 at 2:56 AM, mrts wrote:
>
> On Jan 23, 3:40 am, Malcolm Tredinnick
> wrote:
>> On Thu, 2009-01-22 at 17:27 -0800, mrts wrote:
>>
>> []
>>
>> > A
>> > side note: the `instance` attribute is not used in validator functions
>> > and I can't see a clear use case for it, so it looks like it can be
>> > removed -- prove me wrong please (I do see obscure corner cases where
>> > it could be useful -- if one needs to distinguish between forms and
>> > models in custom validators or do gettatr('something', instance), but
>> > these should really be handled in clean() manually).
>>
>> For models, the "instance" will the models "self" attribute. So that one
>> can do checks based on other information available on the model
>> instance. It's kind of the whole point behind the "model-aware" portion
>> of model-aware validation.
>>
>> Asking that everything like that gets pushed to clean() is being
>> awkward. clean() is for multi-field validation, the individual
>> validators are for single field validation. That doesn't mean the latter
>> cannot use other information available on the form.
>
> As can be seen from the above, fields are already passed to validators
> via all_values = model_instance.__dict__.copy() for multi-field
> validation. But I agree that requiring to override clear() for
> anything more advanced is too restrictive, so let the instance be part
> of the signature.
>
>> I'll try and make time to look at this, along with other recent work in
>> this area, over the weekend.
>
> That would be most welcome, perhaps you can pop by #django-dev for
> more rapid idea exchange?
> >
>
--~--~-~--~~~---~--~~
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: Model-validation: call for discussions
As the uniform all values approach has created a bit of confusion, let
me present a larger example:
Validators in core.validators should not be concerned with either
model or form internals if possible. This is currently straightforward
to achieve by passing all values always as a dict via
form.cleaned_data or model.__dict__.copy() (dict copying is cheap, the
original instance dict is unsafe to pass around).
This makes multi-field validators work uniformly for both models and
fields. Otherwise you have to always handle identical validation
differently for forms and models -- this is extremely smelly in my
opinion.
And now the example:
class RequiredIfOtherFieldEquals(object):
def __call__(self, value, all_values={}, instance=None):
if self.other_field in all_values and all_values
[self.other_field] == self.other_value and not value:
raise ValidationError(self.error_message, REQUIRED)
works both for forms and models with the proposed approach (all_values
is model_instance.__dict__.copy() in model field validation case).
Handling this specially for model instances would be really ugly:
def __call__(self, value, all_values={}, instance=None):
if instance is not None:
if hasattr(self.other_field, instance) and getattr
(self.other_field, instance) == self.other_value and not value:
raise ValidationError(self.error_message, REQUIRED)
elif self.other_field in all_values and all_values
[self.other_field] == self.other_value and not value:
raise ValidationError(self.error_message, REQUIRED)
and entirely unnecessary under the all_values approach.
Everybody is most welcome to prove me wrong :)
--~--~-~--~~~---~--~~
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: Model-validation: call for discussions
I haven't been following everything, but I do have a couple comments
to make here.
On Fri, Jan 23, 2009 at 8:04 AM, mrts wrote:
> works both for forms and models with the proposed approach (all_values
> is model_instance.__dict__.copy() in model field validation case).
One thing to consider is that not all data is always available via the
dictionary, particularly with regard to models. Anything that uses a
descriptor (such as relations to other models) only stores a bare
minimum of information in the instance dict. The rest is retrieved
when accessed *as an attribute*, a fact which is entirely lost in your
example. I understand you're trying not to bundle it too much with the
way models work, so maybe this was intentional, but I do think it's
worth noting, just in case it's not intentional.
> Handling this specially for model instances would be really ugly:
>
> def __call__(self, value, all_values={}, instance=None):
> if instance is not None:
> if hasattr(self.other_field, instance) and getattr
> (self.other_field, instance) == self.other_value and not value:
> raise ValidationError(self.error_message, REQUIRED)
> elif self.other_field in all_values and all_values
> [self.other_field] == self.other_value and not value:
> raise ValidationError(self.error_message, REQUIRED)
>
> and entirely unnecessary under the all_values approach.
I agree that it's a bit ugly, but I'd hardly call it unnecessary,
given the possibly of using descriptors on models. Forms aren't
susceptible to the same problem, because their values are stored in a
true dict regardless. Offhand, I can only think of one way to get a
uniform syntax that works the way you seem to want it to, and that's
by bundling forms and models in some other objects with a unified
interface, designed solely for validation. Something like the
following (untested, coding off the top of my head):
class ValidatableModel(object):
def __init__(self, instance):
self._instance = instance
def __getitem__(self, name):
if hasattr(self._instance, name):
return getattr(self._instance, name)
raise KeyError(name)
class ValidatableForm(object):
def __init__(self, instance):
self._instance = instance
def __getitem__(self, name):
return self._instance.cleaned_data[name]
There could be more methods to be able to iterate over fields and
whatever other niceties you would want to include, but that way you
have a uniform dict interface to work with, regardless of which object
type gets passed in, and it still preserves the ability to use
descriptors on model attributes.
That said, I'm not particularly fond of that solution myself, because
I personally feel that models and forms *should* be treated a bit
differently; the field types for each are just too different in their
capabilities. I haven't been involved with this validation stuff
except for improving file support for it, but I'm not sure a unified
approach would be as big of a win as you claim.
-Gul
(and if I'm missing some obvious bit of history here, feel free to correct me)
--~--~-~--~~~---~--~~
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: Model-validation: call for discussions
After discussing with Honza, we agreed that the dichotomy between
forms and models that was present before will remain, i.e. instance
will always be a model instance if given and all_values will always be
form.cleaned_data.
Honza's rationale was that it's common to have properties in models
and therefore model_instance.__dict__ (or forms.models.model_to_dict)
may be too constraining. Thus, a generic value getter will be used in
validators to provide uniform access to dict values and instance
fields as follows:
def _get_value(name, instance, all_values):
if instance is not None and hasattr(instance, name):
return getattr(instance, name)
if name in all_values:
return all_values[name]
raise AttributeError('%s not found in forms values or model
instance')
class RequiredIfOtherFieldEquals(object):
def __call__(self, value, all_values={}, instance=None):
if _get_value(self.other_field, instance, all_values) ==
self.other_value and not value:
raise ValidationError(self.error_message, REQUIRED)
--~--~-~--~~~---~--~~
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: Model-validation: call for discussions
On Jan 23, 4:38 pm, Marty Alchin wrote: > I haven't been following everything, but I do have a couple comments > to make here. Thanks, interesting points. The get_value approach looks simpler though, so unless you or anybody else disagrees I'll implement this. --~--~-~--~~~---~--~~ 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: #9344 and policy for small bug reports
On Fri, Jan 23, 2009 at 3:14 AM, Julien Phalip wrote: > Thank you Karen for this detailed answer. Your reasoning regarding > this ticket does make a lot of sense. I totally agree with you that > tests are highly important and that this ticket is lacking useful > information for whoever is not familiar with that area of the code. If > I recall, the reason I hadn't written tests for the patch was because > of the way #7769 had been checked in shortly before 1.0's release. I > had thought that, like #7769, the patch was "trivial" enough for not > including tests. But again, as you said, the ticket was lacking > information and I should have at least put a link to #7769 in the > description. I've just done that. I'll think about writing tests but > it seems a bit overkill in this case for something which looks like a > small oversight. > Pointing out where a similar change has been checked in without an added test might incline me more towards doing the same, if I'm feeling adventurous. It might, on the other hand, push me towards thinking "hey, there's a bunch of stuff here that isn't being properly tested...we should correct that before proceeding to fiddle with any more of it." Personally I tend towards the latter reaction...in this particular case I wonder what other methods may be missing here and is there some way to convince myself this ticket is the last of its kind we need to fix. But, if I decide to go ahead and just deal with this one, now, pointing out where a similar change has been checked in without a test doesn't get me past needing to manually verify for myself the existence of the problem and effectiveness of the fix. I'm a terrible Python compiler and like to verify I've run a line of code before checking it in, if only to make sure it doesn't have any syntax errors. For this ticket I still have no clue how to recreate this particular problem on my own or exercise the changed line of code. So, you can wait for someone with more familiarity with this code to have time to look at it. They may know immediately how to demonstrate the problem and verify the change fixes it, or they may feel it's patently obvious that the problem exists and the change fixes it with no syntax errors or anything, and just check it in. Or, if you want to widen the circle of people who may conceivably move the ticket along, you can provide enough recreation detail in the ticket so that even someone who isn't familiar with this area of the code can recreate the problem and convince themselves they've exercised the changed line of code before checking it in. Karen --~--~-~--~~~---~--~~ 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: Decisions needed on signals for add/remove/clear on many-to-many relations
I recently found the time to create a better patch for the m2m
signals, including some tests and documentation and have posted this
patch on http://code.djangoproject.com/ticket/5390
I have taken into account Malcom's suggestions resulting in one signal
called m2m_changed that has the following arguments:
sender
The model class containing the ManyToManyField
instance
The instance whose many-to-many relation is updated.
action
A string indicating the type of update that is done on the
relation: "add", "remove" or "clear".
model
The class of the objects that are added to, removed from or cleared
from the relation.
field_name
The name of the ManyToManyField in the sender class, can be used in
case of multiple m2m fields to the same model.
reverse
False if the 'normal' side of the relation is updated, True if the
reverse side (i.e. on the related model) is used.
objects
With the "add" and "remove" action, this is a list of objects that
have been added to or removed from the relation. The class of these
objects is given in the model argument. For the "clear" action, this
is None .
The signal is emitted _after_ the change for the "add" and "remove"
action, and _before_ the change for the "clear" action.
For an example see the docs and tests in the patch, suggestions for
improvements are of course still appreciated, so please discuss!
Hopefully this will speed up inclusion of this feature into django.
Regards,
-Robin
On Dec 21 2008, 6:26 am, Malcolm Tredinnick
wrote:
> On Fri, 2008-12-19 at 08:42 -0800, rvdrijst wrote:
> > I know there has already been some discussion about addingsignalsto
> > the ManyRelatedManager so that add(), remove() and clear() on m2m
> > relations emitsignals. This functionality, [ORM-18] in the v1.1
> > roadmap, would complement the behavior of pre/post_save and pre/
> > post_delete very nicely and provide a easy and transparent way to
> > track changes to m2m relationships.
> > Since I really like to have this functionality for a project I am
> > working on, I'm trying to push this feature for v1.1alpha. However,
> > some design decisions need to be made, which is why I am starting this
> > discussion.
>
> > The ticket for this functionality
> > ishttp://code.djangoproject.com/ticket/5390
> > which has a patch that works to some extent. It adds threesignals:
> > m2m_add_items, m2m_remove_items and m2m_clear_items. Extra arguments
> > to the signal are the instance on which the field is accessed, the
> > field_name of the m2m field and the list of added/removed objects.
> > The main problem with the patch is the unintuitive sender ofsignals.
> > The signal is sent by the _related_ model, not the model containing
> > the ManyToManyField. For example:
>
> > class Car(models.Model)
> > parts = models.ManyToManyField('Part')
>
> > class Part(models.Model)
> > pass
>
> > Now if we want to handle the signal sent by some_car.parts.add
> > (some_part), we would have to connect the handler to Part:
> >signals.m2m_add_items(add_handler_func, Part)
> > To me, this is not very intuitive. I would like to connect to Car,
> > since that model has the 'parts' field, so this is something I'm
> > suggesting to change in the patch (not that hard to do).
>
> I don't have answers to all the issues you raise in this message, but I
> agree with you here. The ManyToMany is part of Car, so that should be
> the model that is passed as the model, if at all possible. You might
> want to consider passing the other end's model as well, if you can. The
> current parameters you list make it sound like it would be fiddly to
> work out which m2m was changed on a model that contains more than one of
> them. However that washes out in the end, we need to be able to do that.
>
> I also suspect that threesignalsis about three times more than the
> ideal number. A "changed" signal that accepts a parameter for the action
> (added, removed, cleared) and a list of what was added or removed in the
> former two cases would cut down on the number of newsignalsthat need
> to be added. I don't feel too uncomfortable with the overloading of
> purpose here, since the signal is really handling "changes to the m2m
> field" and the parameters are just identifying variations on that.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
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: Feedback from django-roa module
Le 19 janv. 09 à 18:43, David Larlet a écrit : > I got an issue with M2M relations because SQL is hardcoded and I > can't catch it in Query(Set) object: > http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L428 > It is/will be an issue for all non-sql backend (CouchDB for > instance) and I think it should be fixed. Otherwise, I'll need to > hack a large part of Django just to support those relations. Given the amount of answers :) let's discuss a concrete implementation, I just submitted a ticket #10109 about that and I'd love to know your thoughts about the design of the patch (no documentation nor tests for now, for the moment it just works for my project). Regards, David http://code.djangoproject.com/ticket/10109 http://code.djangoproject.com/attachment/ticket/10109/patch_django_10109.20090123.diff --~--~-~--~~~---~--~~ 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: #9344 and policy for small bug reports
Very helpful information from Karen and Russell, thanks. I have written it up for the Contributing section of the FAQ: http://code.djangoproject.com/ticket/10110 --~--~-~--~~~---~--~~ 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: pychecker catches IndexError exception while importing /django/db/models/base.py
Thanks for the suggestion. My app is named 'control' and my django
project name is 'geni'. Running pychecker on the app dir raises a
problem in pychecker itself -- it seemed to be that it was unable to
open one of the sources files:
$ pychecker control/
Processing control/...
Caught exception importing module control/:
File "/var/lib/python-support/python2.5/pychecker/checker.py",
line 620, in setupMainCode()
self._setupMainCode(file, filename, module)
File "/var/lib/python-support/python2.5/pychecker/checker.py",
line 625, in _setupMainCode()
self.main_code = function.create_from_file(file, filename,
module)
File "/var/lib/python-support/python2.5/pychecker/function.py",
line 128, in create_from_file()
file.seek(0)
AttributeError: 'NoneType' object has no attribute 'seek'
However, digging more into the pychecker code I found out that
pychecker was attempting to open the 'control' dir as a file. Then I
checked my pychecker version and discovered that I'm running version
0.8.17 while the latest version is 0.8.18. I upgraded to 0.8.18 and
ran again:
$ pychecker control
Processing module control (control)...
Warnings...
None
However, this last run leaves me skeptical. It does not seem that it
actually imported any modules and I'm getting no prints of
model_module.__name__ so its not importing any of the django models.
Finally I tried running:
$ pychecker control/*py
Processing module admin (control/admin.py)...
model_module.__name__ : django.contrib.contenttypes.models
model_module.__name__ : django.contrib.auth.models
model_module.__name__ : django.contrib.auth.models
model_module.__name__ : django.contrib.auth.models
model_module.__name__ : django.contrib.auth.models
model_module.__name__ : geni.control.models
model_module.__name__ : geni.control.models
model_module.__name__ : geni.control.models
model_module.__name__ : geni.control.models
model_module.__name__ : geni.control.models
model_module.__name__ : geni.control.models
model_module.__name__ : django.contrib.sessions.models
model_module.__name__ : django.contrib.sites.models
model_module.__name__ : django.contrib.admin.models
Processing module forms (control/forms.py)...
Processing module __init__ (control/__init__.py)...
Processing module models (control/models.py)...
model_module.__name__ : models
Caught exception importing module models:
File "/usr/lib/python2.5/site-packages/pychecker/checker.py", line
698, in setupMainCode()
File "models.py", line 539, in ()
File "/usr/lib/python2.5/site-packages/django/db/models/base.py",
line 52, in __new__()
IndexError: list index out of range
Processing module urls (control/urls.py)...
Caught exception importing module urls:
File "/usr/lib/python2.5/site-packages/pychecker/checker.py", line
698, in setupMainCode()
File "control/urls.py", line 39, in ()
File "/usr/lib/python2.5/site-packages/django/contrib/admin/
__init__.py", line 40, in autodiscover()
File "control/admin.py", line 108, in ()
File "/usr/lib/python2.5/site-packages/django/contrib/admin/
sites.py", line 64, in register()
AlreadyRegistered: The model Donation is already registered
Processing module views (control/views.py)...
So its hiccuping on the same issue when importing models, and has a
problem in re-registering a specific model class used in the control
app called 'Donation'. For the last issue, I'm importing Donation in
admin.py using: from geni.control.models import Donation, and I don't
have Donation registered anywhere else. So I'm not sure how to fix
this problem either, except that I don't really care much about
debugging the admin portion of the site so I might just comment out
the register calls.
The original problem remains though.
thanks,
ivan.
On Jan 23, 4:02 am, zvoase wrote:
> I think I might be able to spot where the problem is. Try running
> pychecker on your app folder, rather than models.py.
>
> Let's assume your app is called myapp, so you have a directory
> structure something like this:
>
> myapp/
> -- __init__.py
> -- models.py
> -- views.py
> -- tests.py
> (et cetera)
>
> If pychecker were doing 'import myapp', then the models module would
> be accessible from 'myapp.models'. Therefore, models_module's __name__
> attribute would be 'myapp.models', and the code would run fine;
> 'myapp.models'.split('.') would return ['myapp', 'models'], and the
> [-2] index of that list would be 'myapp'.
>
> However, because you're running pychecker directly on the models.py
> file, its __name__ attribute is just 'models', which raises an error
> in the Django code because 'models'.split('.') returns ['models'] --
> this has no [-2] index, hence the exception.
>
> Just try running pychecker on the 'myapp/' folder (if possible), and
> see if that fixes the problem.
>
> On Jan 22, 10:22 pm, ivan wrote:
>
> > Hi all,
>
> > I'm attempting to run pychecker on my django code (an application's
> > models.py file) and get the following out
Re: Controlling form/widgets output
On Jan 22, 11:53 pm, Russell Keith-Magee
wrote:
> On Fri, Jan 23, 2009 at 5:02 AM, catsclaw wrote:
> > I could have been clearer. I'm not talking about Django Models
> > here; I'm talking about models, views, and controllers from the Model-
> > View-Controller design pattern. Django widgets would correspond to
> > views, while Django forms would correspond to models. In the current
> > architecture, this division is very muddled; I suggested reducing the
> > interdependency and adding a FormRenderer class; that would allow the
> > display elements (widgets) to be handled by a display controller (a
> > form renderer) while the model elements (fields) were handled by a
> > model controller (the form).
>
> Again, either I've misunderstood you, or you don't understand how MVC
> works. Your usage of terms like "model controller" and "display
> controller" certainly serve to confuse matters nicely.
Yeah, I shouldn't talk in shorthand. And my conception of how
this probably ought to work, in a perfect universe, is not only
evolving as I talk about it, but is kind of secondary to the point I'm
trying to make, which is that Django's form classes don't separate the
roles cleanly.
My understanding of MVC is colored from my work with Java, which
used a modified version for their UI framework. There, the View and
Controller are coupled, but divorced from the Model.
> The Form (model) holds a block of form data.
>
> The Widget (view) describes how to render form elements.
>
> The Field (controller) provides a way to extract data from the user
> interface (i.e., process raw blocks of text from a HTTP POST) and
> convert them into data suitable for storage in the model.
But it doesn't work like that in practice. The Form contains raw
HTML in its implementation (in the as_p method, for example) and
contains hardcoded links (through the BoundField class) to widgets to
use for a TextInput or Textarea. A Field contains rules for
validating itself, while the Form has rules (although not many in the
base class) for validating groups of fields. Fields also contain HTML
to inject into widgets.
> > And it's
> > a very limiting conception of what the form functionality ought to do
> > for Django as well.
>
> I fail to see why - but this might be a matter of misunderstanding of
> scope. Django's forms framework makes claims as a HTTP data
> manipulation tool with some minor sideline capabilities as a HTML
> layout tool. For any non-trivial, post-prototype application, I would
> expect the web designer to have much more control over form layout
> than Django's basic form renderer.
Sure, but that's the point. If I had a trivial application, I
wouldn't *need* a framework to help. The web designer should have
control over form layout. But as it is, I can't very easily provide
that as a programmer. And saying "draw this field over here" through
{{ form.field_name }} doesn't let me muddle about with the attributes
set on that field as a web designer.
> Coming up with perfect automated and customizable form layout has not
> historically been a core concern of Django - simply because it is
> impossible to well in an automated way. As a result, there hasn't been
> much focus placed on layout of _forms_.
>
> If this is the feature you're looking for (and it sounds like it might
> be) then sure - there is room for improvement. However - again - this
> could be accommodated without a wholesale teardown of the forms
> framework. What you're calling for is a refactor of
> Form._html_output() to allow for easier customization of form output.
I never called for a wholesale teardown of the forms framework.
All I asked was "Is there any work being done to clean up the way
Django creates forms?" In all the digging around I've done, I'd make
the following suggestions:
1) Define some "standard" attributes for fields (like "max_length",
"max_value", "required") and document them. Similarly, document the
python type each field stores its value internally as, and what types
its clean() method will accept. Maybe this exists somewhere, but I've
been looking directly at the code, and it's not there.
2) Delete (or heavily deprecate) the Field.widget_attrs method.
Widgets are expected to interrogate their associated Fields for this
information.
3) Refactor the Form class into a Form class and a FormRenderer
class. The FormRenderer takes a Form and provides an HTML layout.
The Form doesn't know any HTML, but is otherwise responsible for
everything it currently is.
4) Change widgets (or, for backward compatibility, add an
"advanced" rendering method) which accepts a Field or group of Fields
(BoundField(s)?) and some other standard details from the FormRenderer
(value? id? name?) and produces the appropriate HTML. Widgets can
interrogate their Field(s) for the standard attributes from #1, and
include client-side validation rules where appropriate.
In this architecture, Forms are responsible for mana
Flatpage signal?
I'd like to do some processing any time a flatpage is requested. I can accomplish this by using a view middleware and testing for the resolved view, but it seems a like a signal would be useful so I could have a reference to the flatpage object itself. Any opposition to the idea? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django-smtpd allows you to handle email messages just like Django processes HTTP requests.
Hello, I just started a new project that basically allows you to write email handlers in Django. It could be used in a user-registration application where the user could reply to the email instead of clicking on a URL. I drafted a quick documentation at http://code.google.com/p/django-smtpd/wiki/GettingStarted It shows the basic design of the lib and I'm looking for comments/ suggestions/use cases if that's of interest of anyone on this list. Note that this is still in "hacking" phase so don't consider using this in a production system. Thanks! Denis --~--~-~--~~~---~--~~ 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: Flatpage signal?
On Fri, 2009-01-23 at 18:16 -0600, Jeremy Dunck wrote: > I'd like to do some processing any time a flatpage is requested. > > I can accomplish this by using a view middleware and testing for the > resolved view, Or by subclassing/replacing the existing FlatPage middleware to call your own version of the flatpages() view that issues the signal before or after the response is create (essentially wrapping the existing flatpages()). > but it seems a like a signal would be useful so I could > have a reference to the flatpage object itself. Is this really a common-enough case that we need to add yet another signal in core? Why is flatpages special and not issuing a signal for every template load (which I think would be a bad idea)? Right now, I'm pretty unconvinced about this; it sounds like adding something to core to avoid less than a dozen lines of code in an application for a bit of an edge-case. Regards, Malcolm --~--~-~--~~~---~--~~ 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: django-smtpd allows you to handle email messages just like Django processes HTTP requests.
On Fri, 2009-01-23 at 15:08 -0800, nside wrote: > Hello, > > I just started a new project that basically allows you to write email > handlers in Django. It could be used in a user-registration > application where the user could reply to the email instead of > clicking on a URL. > I drafted a quick documentation at > http://code.google.com/p/django-smtpd/wiki/GettingStarted > It shows the basic design of the lib and I'm looking for comments/ > suggestions/use cases if that's of interest of anyone on this list. > Note that this is still in "hacking" phase so don't consider using > this in a production system. I think you'll get better feedback by posting to the django-users mailing list about this. This list is for the internal development of Django itself, not external applications. Regards, Malcolm --~--~-~--~~~---~--~~ 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: ManyToManyField in both models/forms
On Fri, 2009-01-23 at 00:12 -0800, Evgeniy Ivanov wrote: > On Jan 23, 3:17 am, Malcolm Tredinnick > wrote: > > Addressing this only in the admin would be short-sighted, however. A for > > field that new how to handle reverse relations would be the first step > > and then allowing the admin to use that is the second one. > > > > Maybe better approuch is in model's meta? It will give forms a chance > to do this fancy thing. And it is a kind of logical, since model > really has such relation. No. Because Meta is not about presentation. It's part of the model, which is defining how the data is stored and retrieved. This whole issue is *purely* presentational. Attempting to change the model class to "solve" it is simply using the wrong shovel to hammer in your screws. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
