Re: #9344 and policy for small bug reports

[Karen Tracey]

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

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

[Russell Keith-Magee]

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 %-)

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

[Ivan Sagalaev]

Julien Phalip wrote:
> There probably are a few other tickets in
> that situation (#9404 is another example). 

And http://code.djangoproject.com/ticket/9591 is yet another.

--~--~-~--~~~---~--~~
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: Controlling form/widgets output

[Russell Keith-Magee]

On Fri, Jan 23, 2009 at 5:02 AM, catsclaw  wrote:
>
> On Jan 22, 12:12 am, Jacob Kaplan-Moss 
> wrote:
>> On Thu, Jan 22, 2009 at 4:57 PM, catsclaw  wrote:
>> >   Well, it seems to me that makes for an *extremely* tight coupling
>> > between the model and the view.
>>
>> I'm sorry to be so blunt, but your perception is misguided. Forms have
>> no dependancy upon models, nor do models on forms, nor must views use
>> forms, models, or anything, really.
>
>   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.

I put it to you that the current setup is not in the least bit
muddled. Lets go back to the original MVC definition:

The Model is a domain specific representation of data.

The View renders the model in a form suitable for interaction.

The Controller has nothing to do with display. It exists to mediate
the exchange of data between the model (a store of data) and a view (a
way of presenting data).

And lo - that's exactly what the Django forms framework does!

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.

Now, MVC is a pattern derived from graphical user interfaces, and the
pattern doesn't apply completely transparently to web-based
applications. However, the deviations are fairly minor - the core
concerns are all still there.

You appear to be particularly concerned by the widget_attrs method on
Field. I will concede that this is a slight leakage of the View into
the Controller layer. However, I would draw your attention to two
things:

1) Exactly 1 builtin field makes use of this - CharField -  which
pushes the maximum allowed length to the underlying widget only when
the underlying widget is TextInput or PasswordInput. This could
certainly be made more flexible, but this requires a minor tweak, not
a major rebuild of the entire forms framework.

2) There is absolutely nothing that says you have to use this
attribute data as-is during rendering.   The fields get a list of
attributes - but it's entirely up to you use all, some or none of
those attributes during rendering.

>> > And it's a little difficult for me to
>> > understand what value there is in such a tight coupling--if I've got a
>> > DateField, why can't I have it represented in an HTML page by a
>> > javascript calendar pop-up, or a text box, or three select boxes
>> > (month, day, and year).
>>
>> It's difficult to understand because you've assumed it's impossible;
>> it's not. A quick google search for "django datefield select" ...
>
>   No, no.  You're missing my point.  I was responding to Russell, who
> said "A form contains fields ... Each
> field provides a widget, which describes a HTML element that allows
> that data to be collected."  That description--that forms contain many
> fields, and each field corresponds to a widget--isn't sufficient to
> explain the relationship between forms, fields, and 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.

Think of it like a magical Lego kit - Django provides a big bucket of
bricks, and a big button you can press that will automatically build a
multicolored brick wall. This is fine for prototyping, but the
interesting results happen when someone with design talent carefully
selects the color and placement of bricks and ends up with a lifesize
model of a Stegosaurus.

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 

Re: Controlling form/widgets output

[Jacob Kaplan-Moss]

On Fri, Jan 23, 2009 at 4:28 PM, Matt Boersma  wrote:
> That's an excellent question for the django-users list.  Here we
> discuss the development of django itself.

Bit hasty on the trigger there, Matt. I asked Chris for the specific
problems he's running into; he's responding to me. I appreciate you
trying to keep the signal to noise ratio high here, but please take
the time to check the context before you fire off one of these emails.

Jacob

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

#9344 and policy for small bug reports

[Julien Phalip]

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.

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.

Thanks a lot!

Regards,

Julien

http://code.djangoproject.com/ticket/9344
http://code.djangoproject.com/ticket/9404
--~--~-~--~~~---~--~~
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: Controlling form/widgets output

[Matt Boersma]

On Jan 22, 2009, at 9:23 PM, catsclaw  wrote:

>
> On Jan 22, 12:12 am, Jacob Kaplan-Moss 
> wrote:
>> Why don't we start over here: what is the problem? What did you try  
>> do
>> do? What did you expect to happen? What actually happened?
>
>   Here's another problem I'm stuck at.  I'm trying to determine,
> within a widget, whether I'm being asked to draw a field that is
> required, so I can add JavaScript validation on the form submit.  Is
> this possible?

That's an excellent question for the django-users list.  Here we  
discuss the development of django itself.

--~--~-~--~~~---~--~~
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: Controlling form/widgets output

[catsclaw]

On Jan 22, 12:12 am, Jacob Kaplan-Moss 
wrote:
> Why don't we start over here: what is the problem? What did you try do
> do? What did you expect to happen? What actually happened?

   Here's another problem I'm stuck at.  I'm trying to determine,
within a widget, whether I'm being asked to draw a field that is
required, so I can add JavaScript validation on the form submit.  Is
this possible?

-- Chris
--~--~-~--~~~---~--~~
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

[Yuri Baburov]

Hi Malcolm,

> I look forward to reading your patch. :-)
OK.

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

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

[mrts]

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

[Malcolm Tredinnick]

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.

I'll try and make time to look at this, along with other recent work in
this area, over the weekend.

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: Model-validation: call for discussions

[mrts]

On Jan 19, 11:23 pm, mrts  wrote:
> The directory-based approach is best, I'll go with it -- but it's yet
> uncertain
> when as I have to handle pressing matters at work during daytime.

I've implemented some fundamental changes that need review. The commit
is at 
http://github.com/mrts/honza-django/commit/482086df8d24b99f466152c51d2badee6ee6147d
. The changes are not finished yet, but they should illustrate the
proposed approach. I may fail to see all the negative implications as
I've been mostly addressing fields, not the whole picture. Critique
most welcome.

Changes:

1. consolidate validators and coercers into django/core/validators/
{__init__,typeconverters}.py as suggested by Malcolm

2. make both forms and fields use similar logic in clean():

core.validators:

def clean(field_instance, value, all_values,
field_container_instance):
if value is not None:
value = field_instance.to_python(value)
field_instance.validate(value, all_values,
field_container_instance)
return value

models.fields:

class Field(object):
...
def clean(self, value, model_instance):
if model_instance is not None:
all_values = model_instance.__dict__.copy()
else:
all_values = {}
return validators.clean(self, value, all_values,
model_instance)

forms.fields:

class Field(object):
def clean(self, value, form_instance=None):
if form_instance is not None:
all_values = form_instance.cleaned_data
else:
all_values = {}
return validators.clean(self, value, all_values,
form_instance)

Rationale: make validators that need to use other fields (e.g.
RequiredIfOtherFieldEquals) work uniformly on model and form fields. 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).

3. as seen from above, to_python(), validate() and validators are back
in form fields as this greatly simplifies code. clean() is still
overridable and mostly backwards-compatible. There are a few fields
that have been ported to the new logic in forms/fields.py. Form fields
accept custom validators in `validators` attribute.

4. typeconverters take additional params, mainly intended for custom/
localized date/time input handling, but also useful when overriding
to_python in custom fields:

DateField:

def to_python(self, value, params=None):
 typeconverters.to_date(value, params)

def to_date(value, params=None):
# TODO: use params for date format

This is not yet fully implemented in the current changeset.

Unfortunately I've been unable to contribute as much time as I would
have liked (the fact that the commit is from 2.30 AM my time should
say it all), but I hope to drive field validation to completion soon
after receiving feedback on the decisions above.
--~--~-~--~~~---~--~~
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

[Malcolm Tredinnick]

On Thu, 2009-01-22 at 21:51 +0600, Yuri Baburov wrote:
> Hi, and what's wrong with writing a fix for admin to make "inverted"
> m2m relation to show m2m if specified in list_display list? I know
> it's not easy to do for one who is not django creator, but since it's
> open source... ;)
> 
> Core devs, what's your opinion?

You're proposing something a bit different to the topic of the thread.
The original poster is arguing for a change to the way data is described
in order, solely, to affect the presentation. That's a fairly egregious
hack and I'm strongly against that idea for precisely that reason --
it's symptom patching, not problem solving. I suggested in the
django-users thread that was referenced that approaching this as a form
field problem (which is what it is) is the right approach.

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.

> 
> Such change is pretty logical, short and non-intrusive.

I look forward to reading your patch. :-)

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

[Yuri Baburov]

On Fri, Jan 23, 2009 at 3:58 AM, Evgeniy Ivanov  wrote:
>
> On Jan 22, 6:51 pm, Yuri Baburov  wrote:
>> Hi, and what's wrong with writing a fix for admin to make "inverted"
>> m2m relation to show m2m if specified in list_display list? I know
>> it's not easy to do for one who is not django creator, but since it's
>> open source... ;)
>
> Oh, it could be interesting, but no time even for my native KDE
> org :/
>
>>
>> Core devs, what's your opinion?
>>
>> Such change is pretty logical, short and non-intrusive.
>>
>
> Thanks Yuri, you're the first person who is not against such change.
I'd change/add some part of admin code if i had time.
Single type of search, disability to have 2 views for same model,
widgets & filters not working for large number of items, lack of
read-only items, bad extensibility, some missing hooks and naive ajax
non-compatibility frustrate me anyway. I've written some cool
extensions, but they are private now.

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

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

[Evgeniy Ivanov]

On Jan 22, 6:51 pm, Yuri Baburov  wrote:
> Hi, and what's wrong with writing a fix for admin to make "inverted"
> m2m relation to show m2m if specified in list_display list? I know
> it's not easy to do for one who is not django creator, but since it's
> open source... ;)

Oh, it could be interesting, but no time even for my native KDE
org :/

>
> Core devs, what's your opinion?
>
> Such change is pretty logical, short and non-intrusive.
>

Thanks Yuri, you're the first person who is not against such change.
Maybe they're right and who wants can write a subclass like:
http://www.djangosnippets.org/snippets/1295/
But I feel that with a keyword argument it can be similar to
"through".

Since it's all about keywords (a kind of) I want to point to
http://www.djangosnippets.org/snippets/962/ again.
It's not mine, but there should be no arguing about such change.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

pychecker catches IndexError exception while importing /django/db/models/base.py

[ivan]

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: Controlling form/widgets output

[catsclaw]

On Jan 22, 12:12 am, Jacob Kaplan-Moss 
wrote:
> On Thu, Jan 22, 2009 at 4:57 PM, catsclaw  wrote:
> >   Well, it seems to me that makes for an *extremely* tight coupling
> > between the model and the view.
>
> I'm sorry to be so blunt, but your perception is misguided. Forms have
> no dependancy upon models, nor do models on forms, nor must views use
> forms, models, or anything, really.

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

> > And it's a little difficult for me to
> > understand what value there is in such a tight coupling--if I've got a
> > DateField, why can't I have it represented in an HTML page by a
> > javascript calendar pop-up, or a text box, or three select boxes
> > (month, day, and year).
>
> It's difficult to understand because you've assumed it's impossible;
> it's not. A quick google search for "django datefield select" ...

   No, no.  You're missing my point.  I was responding to Russell, who
said "A form contains fields ... Each
field provides a widget, which describes a HTML element that allows
that data to be collected."  That description--that forms contain many
fields, and each field corresponds to a widget--isn't sufficient to
explain the relationship between forms, fields, and widgets.  And it's
a very limiting conception of what the form functionality ought to do
for Django as well.

> >   Plus, any time you collect a password you need to display it in a
> > form using a password input, not the stock text input.
>
> Again, this is in fact not only possible, but easy::
>
>     class MyForm(forms.Form):
>         password = forms.CharField(widget=forms.PasswordInput)

   Yes, I know this.  That's why I used it as an example.
   This is a case where the field gets asked, during the rendering
process, "I'm drawing a PasswordInput, are there any extra attributes
I should add?" and the field adds the input length to the HTML.  I'm
rather aghast that Fields are expected to know about HTML at all, let
alone be aware of all the available widgets so they can modify them.
   A better design is to have the fields open to interrogation by
widgets.  That way, a widget can ask if there's a limit on the number
of characters in this field.  That way new widgets and new fields work
together, without having to know about each other ahead of time.

> Why don't we start over here: what is the problem? What did you try do
> do? What did you expect to happen? What actually happened?

   Very well.  I'm trying to write a subclass of Form that knows about
Dojo forms, and will render them appropriately.  To do this, I assumed
I would subclass Form (as DojoForm) and then create a widget for each
Dojo form element I wanted to use.  The DojoForm would have a number
of settings relating to the form as a whole, which would alter the way
each DojoWidget rendered itself.
   When a DojoForm gets passed to a template, I could then call a
method in the head of the document that would know what statements to
place in the Javascript, and a different method in the body of the
document which would render the actual form proper.
   What's the best way of doing this?

-- Chris
--~--~-~--~~~---~--~~
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

[Yuri Baburov]

Hi, and what's wrong with writing a fix for admin to make "inverted"
m2m relation to show m2m if specified in list_display list? I know
it's not easy to do for one who is not django creator, but since it's
open source... ;)

Core devs, what's your opinion?

Such change is pretty logical, short and non-intrusive.

On Thu, Jan 22, 2009 at 7:38 PM, Evgeniy Ivanov (powerfox)
 wrote:
>
> Reread what I've written and understand it would be much better with a
> sample:
>
> class User(models.Model):
>groups = models.ManyToManyField('Group', related_name='groups',
> db_table=u'USERS_TO_GROUPS')
> class Group(models.Model):
>users = models.ManyToManyField(User, related_name='users',
> db_table=u'USERS_TO_GROUPS')
>
> This code works fine with existing DB and also it really helps to
> generate proper form from the model. But syncdb fails since it tries
> to create 2 tables with the same name.
>
> class User(models.Model):
>groups = models.ManyToManyField('Group', related_name='groups',
> db_table=u'USERS_TO_GROUPS')
> class Group(models.Model):
>users = models.ManyToManyField(User, related_name='users',
> db_table=u'USERS_TO_GROUPS', create_table=False)
>
> Works fine.
>
> Also there was some discussion in django users:
> http://groups.google.com/group/django-users/browse_thread/thread/50bf564e98954a78
>
> On Jan 22, 12:38 am, "Evgeniy Ivanov (powerfox)"
>  wrote:
>> Hi list,
>> I had to implement M2M editing in both admin forms (something like
>> editing userlist for group and grouplist for user). I wasn't able to
>> find any fine solution, but specifying M2M in both models and creating
>> tables manually (since syncdb tries to create two tables).
>> I herd in the IRC, that such thing (editing in both forms) is
>> abnormal, but I disagree.
>> So I tried to use intermidiary model like described in the docs, but
>> it is really another thing (not "pure" m2m). Another solution is
>> hardcording the form, but it will require extra save code, I don't
>> like it too.
>>
>> I think that if you add special arg (create_table) to ManyToManyField
>> it can be easily implemented using models/fields/related.py:751.
>>
>> If you think it can go, I will create a ticket.
>>
>> Also there is (a kind of offtop) a very cute 
>> thing:http://www.djangosnippets.org/snippets/962/
>> Why isn't it in the native ManyToManyField?
> >
>



-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

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

[Evgeniy Ivanov (powerfox)]

Reread what I've written and understand it would be much better with a
sample:

class User(models.Model):
groups = models.ManyToManyField('Group', related_name='groups',
db_table=u'USERS_TO_GROUPS')
class Group(models.Model):
users = models.ManyToManyField(User, related_name='users',
db_table=u'USERS_TO_GROUPS')

This code works fine with existing DB and also it really helps to
generate proper form from the model. But syncdb fails since it tries
to create 2 tables with the same name.

class User(models.Model):
groups = models.ManyToManyField('Group', related_name='groups',
db_table=u'USERS_TO_GROUPS')
class Group(models.Model):
users = models.ManyToManyField(User, related_name='users',
db_table=u'USERS_TO_GROUPS', create_table=False)

Works fine.

Also there was some discussion in django users:
http://groups.google.com/group/django-users/browse_thread/thread/50bf564e98954a78

On Jan 22, 12:38 am, "Evgeniy Ivanov (powerfox)"
 wrote:
> Hi list,
> I had to implement M2M editing in both admin forms (something like
> editing userlist for group and grouplist for user). I wasn't able to
> find any fine solution, but specifying M2M in both models and creating
> tables manually (since syncdb tries to create two tables).
> I herd in the IRC, that such thing (editing in both forms) is
> abnormal, but I disagree.
> So I tried to use intermidiary model like described in the docs, but
> it is really another thing (not "pure" m2m). Another solution is
> hardcording the form, but it will require extra save code, I don't
> like it too.
>
> I think that if you add special arg (create_table) to ManyToManyField
> it can be easily implemented using models/fields/related.py:751.
>
> If you think it can go, I will create a ticket.
>
> Also there is (a kind of offtop) a very cute 
> thing:http://www.djangosnippets.org/snippets/962/
> Why isn't it in the native ManyToManyField?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---