>From my perspective, this issue is about silent data loss, which is about
one of the worst bugs you can have and one that Django typically tries very
hard to avoid or fix, even if it breaks compatibility.
It is extremely easy to cause silent data loss with the behaviour being
discussed. For whate
I'm not sure about saying that a project is a "container for apps", and
that a project contains "only" settings and "no database models".
At a basic level, a "project" can be just a settings module, but it may
include other things.
Apps that are sub-packages within a project are generally not p
I think that while `extra()` gets a bad rap, it is extremely useful when
creating generic pluggable apps, and I for one would miss it if it were to
be removed.
In a comment on #7231 a few years ago I wrote:
I can't reply to the discussion linked on Google Groups anymore, but wanted
> to add my
s:
>>
>> urlpatterns = [
>> admin.site.get_resolver('^admin/'), # or
>> get_resolver(RegexPattern('^admin/')) to be more explicit
>> ]
>>
>> This would solve the namespace issue for the admin, but it would still
>>
>
> An app doesn't necessarily have to use its own patterns. With that said,
> it's up to the user to make sure it works if they are to mess with the
> app_name. Two conflicting apps can be installed with different namespaces,
> but there will always be a default (the last one, if there is no n
Thanks for taking the time to write up this proposal. I agree on pretty
much all counts, but I do have a few comments:
1)
If an app has templates and view code that are reversing
:, then changing the app name (e.g. by an undocumented
feature, passing a (patterns, app_name) tuple), then all tho
I agree, why not always pass the single auth backend into the login
function?
If the backend is inferred by a single value in the settings and not stored
alongside the user ID, what would happen to existing users who are already
logged in when a second backend is added to the settings and deplo
This sounds good. But will it significantly slow down the rollout of new
features into Django that require deprecation? Also, could features that
are deprecated in an LTS be dropped in the next non-LTS release? e.g. if
1.8 still had a feature that was deprecated in 1.5, could it finally be
remo
I also don't see much benefit in using relative imports. Code is read many
more times than it is written, and I find having the full path makes it
much easier to sort and visually scan imports, and to easily see at a
glance exactly where to find what you need.
If they are to be used, I would re
Right now it seems that for a generic app to support the possibility of
being installed in a URLconf with a namespace, the app author will need to
take care to explicitly define a `current_app` for every call to
`reverse()`, `TemplateResponse`, `RequestContext`, `Context` and `{% url
%}`.
Djan
Hi Aymeric & Adrian,
I didn't see any further discussion or consensus on the issue of the
generic localflavor. The 1.5 docs and (accelerated) deprecation of
localflavor are a little hazy regarding the generic localflavor.
The 1.5 docs say that it hasn't been removed (yet), but doesn't say it wi
Docs have been added (patch should be complete now) and pull request has
been opened, at Anssi's request.
https://groups.google.com/d/topic/django-developers/RrNPfuJxnlM/discussion
Cheers.
Tai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" gr
Hi Aymeric & Anssi,
Thanks for your feedback. I have updated my branch with an implementation
of a new `HttpStreamingResponse` class plus tests and updated the ticket.
Please take a look and let me know if this is moving in the right
direction, and if there is any other feedback. If the approac
Hi Ryan,
I don't think what you are suggesting would be necessary. Stream-capable
middleware could avoid having to handle both cases by simply wrapping
response.content with a new iterator in all cases, if they want
to. Non-streaming responses can still be iterated. They just have fewer
iterat
I have updated the patch on my GitHub repository after some discussion on
IRC with Anssi. The patch applies on master again now, it consumes
generator content on access instead of on assignment, and raises a
PendingDeprecationWarning if you create an HttpResponse with
stream_content=True and th
After discussion with akaarai and mYk on IRC, I have two updated proposals.
OPTION 6:
1. Consume `HttpResponse.content` on first access, so that it can be read
multiple times and eliminate the current buggy behaviour (e.g.
`response.content != response.content`) when a generator is passed in a
It sounds like the preferred solution is still "don't do that", which I
think corresponds most closely with option 1. Simply consuming generator
content in `HttpResponse.__init__()` in all cases would prevent some of the
surprising behaviour we are seeing, but it would completely break any
supp
I'd like to re-visit the discussion surrounding #7581 [1], a ticket about
streaming responses that is getting quite long in the tooth now, which
Jacob finally "accepted" 11 months ago (after a long time as DDN) and said
that it is clear we have to do *something*, but *what* remains to be seen.
Overall, I like this patch. I think it's a little unbalanced that we
provide `Meta.widgets` but no clearly documented way to override other
properties on fields without replacing entire fields.
I think the doc changes are pretty helpful to users who are looking for a
way to do this, and it is a
This seems odd to me. Django is generally a very open and community
oriented project, which strives to consult with the community and achieve a
consensus, resorting to a BDFL decision when necessary, after all sides
have put their case.
Maybe I wasn't following closely enough (apologies if that
I agree with this. HTTP 500 error should not occur due to users attempting
to subvert the system somehow. HTTP 500 errors should only be returned when
an unhandled exception occurs (which shouldn't happen).
Cheers.
Tai.
On Tuesday, 10 April 2012 21:34:07 UTC+10, 3point2 wrote:
>
> The admin si
ile() not per app profiles.
>
> It should be used for generic-esque data about a User. e.g. Email, phone
> number, name, etc.
>
> It should not be used for app specific data about a user, e.g. Default
> Gallery, Notification Settings, etc.
> On Tuesday, April 10, 2012 at 6:01 PM
Alex,
I think the problem with this aspect of your proposal is that it signals a
green light for other pluggable apps to follow Django's lead and provide mixing
which must be added to their `User` model in order to use the pluggable app,
instead of creating a profile model for their pluggable a
Tom,
Thanks for raising those issues. I would just like to add that I hope to see
fields currently in `User` that are required by the admin (is_staff, etc.),
moved to an admin profile model, and not simply made available through mixins
that are still required by every `User` model that gets swa
Alex Ogier,
Is it really better to require users to create their own User model that
behaves like an admin user, instead of just shipping with a self contained
admin user (as a profile model) without the auth component?
If the auth app was purely a stub to connect different profiles and
authen
data, doing database scheme migrations, and
duck typing a single model for use with multiple pluggable apps.
Cheers.
Tai.
On 06/04/2012, at 7:42 AM, Anssi Kääriäinen wrote:
> On Apr 5, 11:29 pm, Tai Lee wrote:
>> But I still don't see how a swapped in `User` model which *has* to beh
On 06/04/2012, at 3:09 AM, Ian Lewis wrote:
> The good part about swappable user models is that you don't need to
> necessarily fix the model's DB fields in advance. Your identifier and
> password's length and other properties can be user defined and can be
> reflected in the DB.
>
> Django c
Are we really sure that we can or should stomach a swappable User model as
a special case?
It's highly likely that I am missing something (or a few things), but
aren't the main benefits of swapping the User model just to avoid making a
backwards incompatible change, and to avoid making `select_
I'm not so sure that it's necessary or even desirable to solve the
"general" problem of swappable models. If anyone can swap any model by
changing a setting, that sounds like a recipe for confusion to me.
Seems to me that the main benefit of the swappable models approach is just
to avoid backwa
I like this proposal because I am a big fan of a stripped down `User` model
which is basically just an ID, whic provides a common hook into
groups/permissions and other django and 3rd party profiles.
What I don't like is the magical `data` bag (accessing `User.data` and
filter lookups), the new
I agree that it is not an ideal user experience to raise an exception while
decoding POST data. However, I think the alternatives are arguably just as bad,
or even worse.
I consider silently replacing characters in user data to avoid an exception
while decoding to be a silent data loss / corrup
I've just created an essay *cough* I mean ticket about the way Django
silently mangles POST data that is incorrectly encoded, and how this can
send someone (like me) down the rabbit hole trying to debug it, thanks to
"current transaction aborted" database errors.
This shouldn't normally happen,
How come? The release that can be downloaded from the site already must
correspond to an SVN revision number, right? Why not tag it as such so that
people can easily get the same code from SVN as from the release tarball?
Cheers.
Tai.
On Sunday, 25 March 2012 22:02:30 UTC+11, Florian Apolloner
This is easy to achieve in your own code. Create your own BaseModel
class that all your models subclass. Instead of using
`.filter().update()`, do this:
def update(self, **kwargs):
"""
Updates the fields specified in `kwargs` and then call `save()`.
"""
if kwargs:
On Feb 29, 8:15 am, Leon Matthews wrote:
> Would it be feasible to add some logic, something along the lines of:
>
> "Template lines containing just tags with no literal content do not
> produce a line in the output (unless of course the tag itself
> produces one)"
I believe that is what has b
I think this discussion is focusing on template tags, not template
variables. Maybe even a subset of template tags (e.g. block level tagsif,
for, block, filter, etc). Template variables and inline tags (e.g. now)
shouldn't have white space stripped.
In 100% of cases I can think of I either woul
s and no
actual content. 99% of the time this is the right thing to do, and we
just need a deprecation path and new template tag so that template
authors can opt-in to the new behaviour now.
Cheers.
Tai.
On Feb 25, 4:37 am, Tobia wrote:
> Tai Lee wrote:
> > I don't think adding {# t
I definitely want to see a resolution to this issue. Django templates
when white space matters (e.g. plain text emails) are painful. But, I
don't think adding {# to the end of lines is easy to understand at a
glance, it doesn't even convey a hint of meaning like "dnl" does, but
either option is pre
It's not that hard to just set up a OneToOneField back to User, and
use signals to automatically create a User when you create your own
User/Profile. Then you can still make use of 3rd party apps that rely
on contrib.auth or contrib.sessions, and also make use of groups from
contrib.auth, etc.
Che
I created a generic `accounts` app which has (among other things) it's
own `Profile` model with a username field and a OneToOneField pointing
at `User`. I added an authentication backend to my settings that
checks usernames from my model. Of course there are other supporting
components, forms, sign
I found that Alex's `django-ajax-validation` works pretty well for
this and I think it works the way you described. Perhaps it could be
updated and included into Django core, if there is good support for
it.
https://github.com/alex/django-ajax-validation/
Cheers.
Tai.
On Feb 4, 8:03 am, Adrian
Instead of trying to dynamically change the manager used for reverse
relations or any manager/queryset (either by getting and then throwing
away the default manager, or some other method), or applying manual
filters to achieve the same result, there is another alternative.
Instead of:
{{{
reporte
Ian,
I agree that there are a lot of different ways that form data can be
submitted to Django, including near endless combinations of multiple
Django forms, multiple HTML forms, AJAX, etc.
If we reduce the scope of our discussion and consider only a Django
form (forgetting HTML forms and AJAX) an
t initial value of "".
>
> Neither error condition is optimal, however A has the additional downside
> that this error is completely outside of the control of the developer whereas
> B is the result of developer error and is under his control.
>
>
>
>
>
>
>
Tom, the problem is not caused by using `exclude`, it is caused by not
using `fields`. If you use `exclude` or simply don't specify `exclude`
or `fields` then all fields will be included. Thanks for your other
example and description of the problem, I just wanted to clarify that
it is not only a pr
Optional or required is not the same thing as important. It is
entirely valid to have important but optional fields on a model.
For example, a field that contains a string reference to a python
callback function that modifies the behaviour of some model methods
when set.
We use this on a Broadcas
There is a potential for data loss with optional form fields that are
(for whatever reason) omitted from an HTML template.
For example, if we take an existing model form and template that
works, add an optional character field to the model but fail to add a
corresponding field to the HTML template
I have had difficulty in finding an easy way to add common methods to
querysets and managers for multiple models in Django.
I solved the problem in my projects by defining a custom `Manager`
class which defines `use_for_related_fields = True` and also overrides
`__getattr__()` to look for queryset
I've run into a bug that is exposed when using defer() or only() with
select_related(). A couple others have come across it, and there is an
existing ticket.
Exceptions appear to be silenced somewhere under normal circumstances
when evaluating `queryset` objects, which made it difficult to track
d
Why is ROUND_HALF_EVEN superior? Perhaps for statistics, where
rounding all halves up would skew results, but I guess not for most
other cases.
If the default rounding behaviour produces different results than a
regular calculator, common spreadsheet and accounting software or even
human (mentally
On Oct 4, 11:17 am, Russell Keith-Magee
wrote:
> I'm completely agreed that the 'soft' deprecation is useful. I'm just
> complaining about the ambiguity in the language: "We're deprecating
> this feature by marking it PendingDeprecation...".
What about just changing "PendingDeprecation..." to
"
Is this really much better than using your own custom manager as the
default automatic manager (used for reverse relations) with
`use_for_related_fields = True`?
Your custom manager could do nothing to filter results by default and
so behave the same as the default automatic manager, but provide
a
On Jul 9, 12:24 pm, Karen Tracey wrote:
> I'm strongly against that idea. Swallowing errors makes it incredibly
> difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG` setting to
> turn off much of the error-silencing currently done in template processing.
> Yes, that means differen
On Jul 8, 11:31 pm, Jacob Kaplan-Moss wrote:
> > [...] but some of Django's own template tags (e.g. `widthratio`) don't
> > adhere to
> > this policy.
>
> These are bugs, and should be fixed.
Thanks for this clarification. I will try to review the built-in tags
and submit some patches to fix t
I'd like to raise the topic of exception handling in templates, to see
what people think of the current state and discuss possible
improvements.
I personally find it confusing to use and create template tags at
times, due to exception handling. Sometimes exceptions are supposed to
be silenced, and
On Jun 17, 3:41 pm, David Cramer wrote:
> I'm not suggesting changing the behavior (again due to the
> compatibility concerns), but I completely agree with the original
> poster(s).
>
> Also, in my experience it's a much less common case that you're
> wanting an "I agree" checkbox in your form, ve
This has been discussed many times in the past. For better or worse,
we're stuck with the current behaviour for backwards compatibility.
I personally think it's better this way. Without this behaviour, it
would be a PITA to implement forms that have a "required" boolean
field (must be ticked) with
On Jun 3, 9:32 pm, Jonathan Slenders
wrote:
> I really never want to have the {% block %} names of B/C in previous
> example to be available for overriding in templates which inherit from
> A. This would even cause unexpected collisions between block names.
> The author of the include B, is not
G'day,
There are several open tickets (some getting quite old now) that all
stem from the inconsistent behaviour of the {% include %} tag. When a
quoted string is used for the path, it is treated as a special case
and the include is executed at compile time. Otherwise, it is executed
as the templa
I thought Django already did option 1. If it doesn't, why not? What
are the possible edge cases? Using a date field named "date" as a
foreign key to another model that also contains a "date" field?
On May 10, 1:47 am, Ulrich Petri wrote:
> Currently there are at least 4 open tickets [1-4] that p
On May 3, 9:43 am, Russell Keith-Magee
wrote:
> This stems back to the design motivation of Django's template language
> -- you shouldn't be doing math in the template. Instead, you should be
> doing your math in the view, and providing the template with a
> pre-calculated result.
>
> So, my incli
On Mar 28, 4:08 pm, Justin Holmes wrote:
> By "current app," do you mean the app which contains the view to which
> the current URL is mapped?
I mean the "namespace" (instance name) for the requested URL or the
"current_app" attribute of a context object which is supposed to be
used as a hint for
Now that 1.3 is out, does any core dev have an opinion, feedback or
suggestions on this?
I've solved my immediate need with two template loaders (subclasses of
the app_directories loader) that use thread locals. One prefixes the
requested template name with the app name and the other prefixes it
w
If we're talking about the lowest common denominator and keeping
things simple, this is what I think we'd have:
myapp1/
myapp2/
myproject/
-django.wsgi.sample
-manage.py
-management/
--commands/
---myproject_mycommand.py.sample
-media/
--myproject/
---readme.txt
-models.py
-settings.py
-static/
--
I also don't think it should be considered a security vulnerability to
reveal that an authenticated user does not have permission to access
the admin (or any other) app.
If the credentials are valid and they authenticate against the defined
authentication backends, then we should assume that we ar
I have a generic app which includes base templates (for HTML
documents, emails, etc.) and also template tags that render a template
(for form fields, pagination forms/links, filter forms/links, etc.)
Sometimes I have a project that has several other apps installed which
both use the base template
y of uploads on other
higher traffic sites across different browsers and using different
server side technologies, to see if this really is typical.
Cheers.
Tai.
On Feb 5, 2:23 am, Jacob Kaplan-Moss wrote:
> On Fri, Feb 4, 2011 at 2:45 AM, Tai Lee wrote:
> > It seems to happen with ve
It seems to happen with very small file uploads as well. I've seen it reported
with 30KB uploads, while at the same time 60MB uploads work. If I can't find a
problem with the server causing disconnects, and it is actually on the client
side, I'll just have to continue to ignore the exception rep
eing passed through in the WSGI
> environ dictionary so it could be compare against. For example something
> like:
>
> try:
> data = environ['wsgi.input'].read()
> except wsgi['wsgi.input_exception], e:
> # ignore it
>
> In summary, no real pr
There are many questions about this on django-users. The usual answer
is to ignore the errors, which are probably generated as a result of
the client prematurely terminating a connection, usually during an
upload.
Nobody seems to be able to reliably reproduce the error, and it seems
to happen with
On Jan 13, 5:06 am, Don Spaulding wrote:
>
> I can't speak to the number of templates actually in the wild that
> rely on the old behavior. I will say that the debug template has been
> "relying on the bug" since 2005. By my estimation, that makes nearly
> every template ever created a candida
If we can, I would be in favour of treating the old behaviour as a bug
and not having to support it while it follows a deprecation path.
However, either way, if the new behaviour stays (and I definitely
think it should) I think we should update the docs to clarify that
there was a change in behavi
I just discussed this with Don on IRC. An example of the use case
described is at:
http://djangosnippets.org/snippets/1016/
The fix for this use case is easy. Pass a list of `(button.func_name,
button.short_description)` tuples as `buttons` in the context instead
of passing a list of callables. B
There are a few tickets that I believe are or should be RFC that I
would like to see committed before the 1.3 feature freeze kicks in,
which I just heard was very soon now. If anyone has time, could they
please review the following and bump to RFC or provide additional
feedback if they're not yet r
I've been using the patch from #1105 in my local branch of Django for
a long time now. To be honest, I've hit the need to have access to the
existing context in a simple_tag far more frequently than the need to
return a single value as a named variable in the context, and I'm
definitely +1 on addin
I believe that only the reporter, owner, and CCs are notified when an
update is made, not anyone who added a comment. Unless a reviewer adds
themselves to the CCs when providing feedback or assigns the ticket to
themselves (which would be unlikely, when leaving feedback that the
reporter needs to t
This has been my experience, as well. I know this is an open source
project and that we're all volunteers, but I have found it it
extremely disheartening and a discouragement to further contribution
when I have invested the time to do the right thing and submit a
detailed report, with patch and doc
I'm in favour of closing tickets with "need more info, re-open when
you have it or if you disagree" because it clearly puts the onus back
on the reporter to re-open the ticket after addressing the feedback in
order to see any progress.
Leaving tickets "open" with potentially yet another status or
The following two tickets are fairly trivial, with docs and tests,
both accepted by a core dev 7 plus months ago.
http://code.djangoproject.com/ticket/12398
http://code.djangoproject.com/ticket/13291
This one is 2 years old and has no docs (but I'm not sure if they are
required). It was marked as
I like the idea of needmoreinfo as a resolution, which makes it clear
to the reporter that they need to take the next step to re-open the
ticket with more info. I don't think that closed with "invalid" and a
comment makes this as clear.
However, I think there's another problem area where we need t
I think that since Proxy models only affect the methods, properties
and way the data is used (not the actual underlying data itself), it
is appropriate to compare User and UserProxy as equal. To not treat
them as equal, you will need to be sure that you never pass a
UserProxy object to a 3rd party
Hi Russ,
On Oct 5, 11:48 am, Russell Keith-Magee
wrote:
> There have been a couple of suggestions recently that the contributing
> guide should be distilled into a specific HOWTO for new users. I
> suppose the idea here would be for the contribution guide to be the
> letter of the law, and the H
Hi Jacob,
Thanks for your feedback.
> For (1) check out http://code.djangoproject.com/wiki/Reports(it's
> linked in the nav). If there's anything missing there, please feel
> free to add it -- it's a wiki page. Let me know if you need help
> figuring out the linked query syntax.
I wasn't able to
On Sep 30, 7:22 pm, Russell Keith-Magee
wrote:
> What is also needed is a whole lot more people volunteering. Any
> suggestions on how to get more people doing the entirely unglamorous,
> but completely necessary work will be gratefully accepted.
I'd like to suggest (1) easy to find and use pre-
own HttpResponse manually and return that,
rather than using a helper function like direct_to_template?
Cheers.
Tai.
On Sep 15, 2:25 pm, Tai Lee wrote:
> I'm going to try and preempt a possible objection that has been raised
> in previous discussions on this subject.
>
> Won'
I'm going to try and preempt a possible objection that has been raised
in previous discussions on this subject.
Won't this change require a lot of repetitive logic to be shifted into
middleware functions? All middleware authors will now need to inspect
the response and find out if they can make th
On Jul 14, 11:15 pm, Russell Keith-Magee
wrote:
>
> I'm not wildly enthusiastic about this. You've posted this snippet (or
> something like it) a couple of times, and every time my immediate
> reaction has been "You're in a twisty maze of endtemplatedir tags, all
> alike" :-)
>
> I can see what
Hi Carl,
On Jul 14, 11:44 am, Carl Meyer wrote:
>
> I totally agree with this. I think very similar results can be
> achieved in the form-rendering system just with an optional parameter
> to a "form/render_form" tag that specifies a "base path" for finding
> template widgets for this form render
Hi Russ and Carl,
On Jul 14, 5:55 am, Carl Meyer wrote:
> Hi Russ,
>
> On Jul 13, 12:11 pm, Russell Keith-Magee
> wrote:
>
> > My manifestation of this problem is slightly different -- it's the
> > issue of how to ship a widget library that can be used anywhere. I
> > suppose one argument here i
I really like the idea of using Django templates instead of generating
markup in Python, which should enable designers (who don't know and
don't want to know Python) to customise markup in almost any way they
like. We just need to add a few hooks that will make it easier to
override specific templa
Regarding the DOCTYPE problem, I don't think it's appropriate to set
the DOCTYPE as a setting for an entire project. As many have pointed
out, each bundled app could define a different DOCTYPE in their base
templates.
It doesn't make sense to apply a DOCTYPE setting to the context of a
form either
I didn't think about the author of a `HttpResponse` subclass needing
to know all potential middleware that will not work with that
particular response class. That is definitely a problem. However, I
don't think that exposing a capabilities based API on `HttpResponse`
is the answer.
If we do that,
On Feb 21, 7:46 am, Forest Bond wrote:
> Okay, I think "disabled_middleware" is a bad name because it doesn't actually
> imply that all middleware should be disabled. Anyway, it seems like
> middleware
> could just check if isinstance(response, StreamingHttpResponse).
I'm not sure I follow your
See also #7581, which has a patch that I have been using in my local
Django branch for over a year without issue. My use case is that I
need to generate large amounts of data in CSV format and stream the
response to avoid timeouts. I wouldn't mind `HttpResponse` consuming
`content` immediately if w
It feels like a catch 22 situation. We need someone to champion and
shepherd design changes into trunk, but we can't assign such a role to
somebody who hasn't met the criteria that each core committer must
meet. To quote the Django documentation, any design czar or core
designer should have "a long
On Jan 9, 12:36 am, Honza Král wrote:
> On Fri, Jan 8, 2010 at 11:59 AM, koenb wrote:
>
> > On 8 jan, 10:03, James Bennett wrote:
>
> >> Suppose I have a ModelForm and call save(commit=False) to get the
> >> instance so I can do some more work on it. I'm basically saying to
> >> Django "I don't
It makes sense to me that the developer should first check that their
form is valid and second check that their model object is valid when
calling ModelForm.save(commit=False). This could be done by having the
developer check the result of model.full_validate() before calling
model.save(), or by ha
Speaking of the ways in which a namespace can be specified or
provided, #11642 might be relevant here.
http://code.djangoproject.com/ticket/11642
It feels a little cumbersome to me to require users to either manually
specify a namespace or import a different object (than just the usual
urls modu
On Oct 14, 10:45 am, Tobias McNulty wrote:
>
> Okay, let's pick something other than 'messages' and stick to it. I'm
> fine with "notifications", "notices", and maybe even "notes", but the
> last one is a little ambiguous. Other ideas?
My personal bike shed is named "alerts", but other than th
On Aug 15, 3:19 am, ccahoon wrote:
> This is the case, yes, if the HTTP and GZip middleware are not used.
> We had to modify both of those to make sure they didn't consume the
> content generator to find the Content-Length. I imagine, IF we wanted
> to, setting the Content-Length header could be
1 - 100 of 171 matches
Mail list logo
