I'm only using Django 1.1 as part of CI tests, and they have started
failing recently because of this, so I'd be happy to see it fixed.
--
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@g
$ pip install django==1.1
Downloading/unpacking django==1.1
Could not find a version that satisfies the requirement django==1.1 (from
versions: )
No distributions matching the version for django==1.1
This was working perfectly well not so long ago. I notice 1.1 isn't listed
on PyPI either:
http
> Folks, you seem to have missed Russell's point. Even if 100 people +1
> this, it's meaningless. That's a tiny fraction of this mailing list's
> readership, much less of the Django community at large.
If the maintainers of Django want to make a personal taste-based
decision rather than a popula
Not to harp on about this, but I never understood not supporting multi-
line tags, in particular if it doesn't affect performance and really
is as straightforward as suggested by the OP.
Yes, they are only useful in a limited set of cases (albeit "rare" may
be overstating it), but so are multi-lin
> No, it wouldn't (at least, not completely). Jinja wouldn't extend
> Django's TemplateSyntaxError class, so using the approach you
> describe, Jinja's TemplateSyntaxErrors wouldn't break the debug page,
> but you wouldn't get good template error feedback either.
FWIW, I don't think that's an issu
I haven't looked at the patch yet, but I'd really like to be able to
change an app's name (and with it the names of the database tables),
which I thought was something that this proposal would include. So
fwiw, I personally would like to see it in 1.1.
Michael
--~--~-~--~~
> I've got a workaround for that which works pretty well:
>
> http://code.djangoproject.com/wiki/ExtendingTemplates
Hm I might be misunderstanding, but it seems you're trying to
workaround the situation where two templates might not be uniquely
addressable. I can't quite make the connection to th
I remember this coming up on django-users and IRC once or twice, and
never thought too much about it, but currently, template inheritance
and includes don't work together at all:
* Blocks included in a parent template cannot be overwritten in a
child template.
* Blocks from an include in a child
This should have been more obvious to me in the first place. The
problem only exists for an empty string value (the choices in my
particular case hat string keys, and the field was not nullable).
Tries this case:
>>> w = Whiz(c='')
>>> w.save()
>>> w.get_c_display()
u''
Expected:
u''
Got:
Previously, get_FIELD_display(), for a blank or unknown value of
FIELD, return the value unchanged, e.g. say None or an empty string.
After the change, it returns the automatically inserted blank choice
(---). This is due to it now using field.flatchoices, which is
dynamically generated throu
> In summary, it is called 'QManager', and is a Manager subclass which
> helps developers create Managers from Q objects. QManager instances
> can be joined by & and |, and by using the negative operator you can
> create a QManager which is the complement of the original.
Whether included in core
> learn the tool. I don't really have access to a windows server that
> could handle an instance, but I'm sure someone does.
I have an unused VMWare instance running Server 2003 that I suppose
should be able to do the job.
Michael
--~--~-~--~~~---~--~~
You receive
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
Why stop at widgets? Let's say I want to change just the label of a
field, or
> Yeah, hgsvn is one-way, which git-svn has the "dcommit" command
> which'll commit back to SVN. I'm really not much of a git fan, but
> git-svn makes a better svn than svn does, if you know what I mean.
FWIW (I'm currently playing around with all three of them), bazaar
appears to support pushing
> So that leads me to my decision to put this SQL-code into a model so
> that the query is performed faster than by the view.
I think what you might be looking for is a custom (default) manager
for your model that adds your base query to each QuerySet interaction.
I suppose depending on what that
> I'd be +1 on this, on the condition that there be some way to supress
> errors, something like this.
>
> {% for item in list %}
> {{ item.title }}
> {% silent %}
> {{ item.owner }}
> {% endsilent %}
> {% endfor %}
That seems very clunky to me. If going down that route, I'd prefer to
either enab
On Apr 14, 10:02 am, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote:
> as I will still have to apply the decorators
> manually to all views instead of enabling them programmatically, and I can
> still not call the view more than once etc.
I needed something similar a while ago and came up with this:
> It's a bug (#5937).
Thanks Malcolm. I was doing a search, but had trouble with the terminology.
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send emai
class Feature(models.Model):
content_object = generic.GenericForeignKey()
class Review(models.Model):
features = GenericRelation(Feature)
class Person(models.Model):
features = GenericRelation(Feature)
>> Person.objects.create() # id = 1
>> Review.objects.create() # id = 1
>> Fea
19 matches
Mail list logo
