Christopher Lenz wrote:
> I'm all for a feature-freeze for MR: IMHO the remaining bugs should
> be fixed, and the contrib apps (such as comments) updated to the new
> API, but *before* there's any more major refactorings. Make another
> minor release, and push -- for example -- validation-aware mo
Russell Keith-Magee wrote:
> In addition, your alternative would have 'X = article.reporter_set'
> provide useful data, but 'article.reporter_set = X' throw an exception
> - this asymmetry strikes me as much more confusing than the absence of
> strict name binding.
This is a good point, but at le
Russell Keith-Magee wrote:
>1) What should be the behaviour of __set__ for descriptors where
> multiple values are allowed (ForeignKey, ManyToManyField)?
> Known Objections:
> Kieren Holland suggested that Article.reporter_set = [r1,r2] implies
> that reporter_set is an ordered collection, becau
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED] > wrote:
> >
> > My concern is that you end up with this:
> >
> > book.authors = [author1, author2]
> > book.authors == [author1, author2] # not true
>
> Well, if we want to get picky l
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
> >
> >
> > If it were a 'set' method assignment would not be possible and an
> > exception hinting to use 'set' would be raised.
>
>
> (Damn English language..
Russell Keith-Magee wrote:
> On 3/3/06, kmh <[EMAIL PROTECTED]> wrote:
>
> > Assigning a list implies assigning an order. How about:
>
>
> book.authors.set([author1, author2])
>
>
> This doesn't address the problem - what is the 'set' behavi
Russell Keith-Magee wrote:
> I can see the merit in finishing the descriptor protocol
> for all m2m objects. So:
>
> book.authors = [author1, author2]
> would be equivalent to
> book.author.clear(); book.author.add(author1, author2)
Assigning a list implies assigning an order. How about:
book.au
Maniac wrote:
> I think it shouldn't be magical here because user shouldn't use this
> often at all. I think automatisation of converting a form to an object
> should happen a level higher like this:
>
> c = Crime.parse_form_data(request.POST)
>
> parse_form_data would iterate over field objec
I like the idea. Perhaps you could have a class method
without_validation() for the bulk upload?
Maniac wrote:
> Adrian Holovaty wrote:
>
> >* Specifically, validation happens on Model.__init__() and
> >Model.__setattr(),
> >
> Ouch... Last time this was discussed this was considered bad thing (
Robert Wittams wrote:
> Adrian Holovaty wrote:
> >
> > This change, at a glance, looks good. Go ahead and commit it.
> >
> > As for renaming all() to cached() and/or making SomeModel.objects a
> > QuerySet directly and having to deal with cached vs. non-cached query
> > sets -- we've already had t
Joseph Kocherhans wrote:
> Here's what I've come up with for django.shorcuts.views. Anything I've
> missed? Anything that should *not* be included? I think this covers
> basic to advanced views and should really simply the first 10 lines of
> most people's view modules. I've left out any kind or a
Adrian Holovaty wrote:
> On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
> > Good idea to rename DjangoContext. My favorite alternative:
> >
> > DjangoContext --> Context
> > Context --> PlainContext or SimpleContext
>
> I like this a lot! Simple
> Let's go ahead with this one: django.core.template becomes
django.template.
>
> While we're at it, let's rename DjangoContext to something that
> reflects the fact that you pass in an HttpRequest object and it has
> context processors. RequestContext, SuperContext, FlexContext,
> AdvancedContex
Adrian Holovaty wrote:
> Let's go with the http package, with an __init__.py in it, simply
> because it makes it more flexible to put stuff in there in the future.
This raises an issue of coding style: my feeling, though PEP 8 (the
python style guide) doesn't rule on it, is that __init__.py is
i
Joseph Kocherhans wrote:
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> > > Could you follow some uniform way of the pluralization of module names?
> > >
> > > I mean why there is django.shortcuts.views (plural) and django.form
>
Hi Cheng,
I had expected that flatten_data would "do the right thing" but as you
demonstrate it seems that the manipulator doesn't flatten it correctly
either.
The CheckboxField expects booleans to be "on" for True and "" for False
so i guess this is what the manipulator should flatten to, rathe
OK typo there. Clearly time for sleep. Try this:
===
from django.utils.datastructures import MultiValueDict
def profile_edit_info(request, user_id):
try:
manipulator = users.ChangeManipulator(user_id)
except users.UserDoesNotExist:
raise Http404
if request.POST:
# flatten e
OK, so it looks like do_html2python requires a MultiValueDict. This is
getting ugly, but try:
from django.utils.datastructures import MultiValueDict
def profile_edit_info(request, user_id):
try:
manipulator = users.ChangeManipulator(user_id)
except users.UserDoesNotExist:
rais
How about this instead?
The view code:
==
def profile_edit_info(request, user_id):
try:
manipulator = users.ChangeManipulator(user_id)
except users.UserDoesNotExist:
raise Http404
if request.POST:
# flatten existing data to strings
new_data = manipulator.flatten_dat
Rewind a bit.
Actually, that recipe you were using was designed to prevent people
from updating fields that they aren't supposed to by posting faked form
fields. So don't do what I just suggested because people could change
their status to superuser or whatever by posting fake form fields.
So
Cheng Zhang wrote:
>if request.POST:
> new_data = request.POST.copy()
>
> # here I am filling in fields from the fetched object
> # to make sure that the user can't pass in security relevant
> # data. Make sure that you turn your values into strings,
> # as that's exp
hugo wrote:
> >I like this idea, but I think that shortcuts of whatever should use
> >explicit imports such as
> [...]
> >This makes it a lot easier to tell what exactly you'll get if you
> >import django.shortcuts.
>
> Yes, most definitely. The "simplified API importer" should only do
> explicit
Hi Adrian,
Your opinion of the my suggestions fits pretty closely with mine.
Adrian Holovaty wrote:
> On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
> > django.utils.httpwrappers -> django.http
>
> +1. I'm a big fan of this. django.http would get that&#x
Jacob Kaplan-Moss wrote:
> One altertative to your proposal that Adrian and I tossed around at
> one point was to alias certain "normal" modules into a set of
> "tasks." That way writing a view would become::
This would certainly be a vast improvement from an end-user's
perspective and it would
Aaron Swartz is no diplomat but he made some good points in this rant:
http://www.aaronsw.com/weblog/rewritingreddit
The magic-removal branch addresses the ORM issues he raised. A
remaining problem is the disorientating namespace.
View modules typically begin with ugly boilerplate like:
---
zagorot wrote:
> when I get rid of this below:
> -
> {% ifequal mod(forloop.counter0,4) 0 %}
>
> {% endif %}
> -
> It works fine.
> What's happened?
The end tag for {% ifequal %} is {% endifequal %}.
Kieran
p.s. the django-users list is a better place to
I like the general take. My first thoughts:
If db provided an appropriate __all__ then this would be more succinct:
from django.db import *
class Toy(Model):
name = CharField(maxlength=30)
colour = CharField(maxlength=30)
class Person(Model):
first_name = CharField(maxlength=30)
I agree with Robert. Too much magic. It would be a shame not to take
the chance to get rid of it if changes of this significance are
planned.
MODULE_CONSTANTS is ugly. Perhaps I should get over this, but I find
it so ugly that I often end up explicitly importing things inside each
method of my
Hi there,
Django rocks. Or should I say it swings? (Probably a tiresome quip
already - sorry!). Thanks to all the developers for your excellent
work, not only in creating a fine web development framework, but also
in establishing the beginnings of a great community to support it.
In playing a
29 matches
Mail list logo
