above issue, at least until that day when we can kill
DJANGO_SETTINGS_MODULE and import-time exceptions in Django.
Carl
> I'm asking because I'm using an unholy monkey patch [2] that
> shamelessly uses __import__ and I'm yet to discover why that's
> troublesome. It's been in heavy use for 18 months
ll withdraw my concern. But it seems to me it's at
least worth some public discussion before locking ourselves into an
API.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
value is
expected to indicate SSL vs non-SSL. The proposed hook (currently
implemented in django-secure) already accounts for this variation by
requiring the user to explicitly specify the header and value that
should indicate an SSL request.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (
s you are
absolutely sure that your front-end proxy enforces the header correctly.
Perhaps we could also supply some advice on how to check that?
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.moz
n the full session/auth stack, which likely depends on some
kind of external session store - the 500 error could easily be due to
that external store being unavailable in the first place!)
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux
setting is
only for user-uploaded media, which is not something that should be
needed on a 500 page).
Thoughts on this?
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk55DnMACgkQ8W4rlRKtE2czWQCfWXkYN9CznrNd7
r is
undocumented, counter-intuitive, arguably simply a bug, and the
consequences of the change are minor and easy to correct for. So yes, I
agree :-) And I also filed #16856 [2] to address the "no way to clear
it" issue.
Your observation that "depth" is currently sticky while fi
uot;wontfix", and that is something that ought to be right
up top. So there may be no simple way to address this.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk55AqEACgkQ8W4rlRKtE2dxGwCgxuubCeRLq6
b, I just
think we may as well start with the lower-hanging fruit here.
Databrowse could easily be spun off into an external app if anybody
cared to maintain it.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.or
plain what it means, which tickets should get a milestone set,
who should set it, and under what conditions it should be removed or
bumped)?
Thanks,
Carl
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/bf7da09f1f5881dc/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10
tests/__init__.py.
But I'm getting off-track -- these should be separate tickets anyway. If
you'd like to file the first one and upload a backwards-compatible
patch, I'm +1 on the concept.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using Gn
for that GSoC, he or Arthur
Koziel (the student) can probably comment most knowledgeably about what
needs to be done.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5ub0QACgkQ8W4rlRKtE2cISACgh/lYqh
on't know if a DOS attack is possible by sending many request with very
> long CSRF tokens?
>
> IMHO it's a good idea to check the length before do anything with it.
Sanity-checking the length sounds reasonable to me - do you mind opening
a ticket for this and attaching your patch?
Thanks
onfirms that its up. Either its a
localized issue, or if it was down, it isn't any longer. I've closed the
ticket "worksforme".
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla
key goals with this
> push is to include just enough functionality that we can improve this
> particular aspect of Django.
[snip]
> I'm really excited that we finally have the momentum to bring this
> important change to Django!
Me too. The plan looks great to me.
Carl
-BEGIN PGP S
the overblown rhetoric. I can name fifteen designers
who code off the top of my head (more than I could name who don't).
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5hBdwACgkQ8W4rlR
a "generic" way. In general I don't see any problem
with making specific included form templates for specific needs. I'd
probably just call these "profile_form.html" and "display_name.html", if
those are names that make sense in the context of the project. I don't
know about your projec
is use of the flag is unrelated to fixture loading, the
fixture-loading fix should not change the value of the flag for any backend.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
m very hopeful that Armin's work can
make rendering speed a non-issue. No pressure, Armin ;-)
Carl
--
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 unsu
. I
think this system will be flexible enough to allow template authors to
use fieldsets with forms easily and non-repetitively.
Carl
[1] http://pypi.python.org/pypi/django-form-utils
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
In case anyone's interested in this but isn't following the ticket,
I've attached an updated patch there using a variant of Vinay's
suggestion, and with some shim code to address backwards-compatibility
concerns. Reviews welcome.
Ticket is at https://code.djangoproject.com/ticket/16288
Carl
gt; is False)
True that it's used for that, but it doesn't exclusively mean that;
therefore I think DebugFalseFilter is a clearer name than
ProductionFilter. I would have to look at docs or implementation to be
confident I knew what the latter did; not so for the former.
Carl
--
You received
ilter allows through, but AFAIK there's no name for
> "not debug mode".
The name is fine - thanks for the patch! I realized there's still a bit
of a back-compat issue, I've commented on the ticket with a possible
solution. I'd like to get Russ' take on it, if he's ok with the plan I
can
l-purpose, but the backwards-compatible behavior can be maintained.
Matt, if you'd be willing to open a ticket for this, that'd be helpful.
If you feel like putting together a patch using the Filter approach,
that'd be even better ;-)
Carl
[1] http://docs.python.org/library/logging.html#filter-obj
even remove it outright.
I agree with all of this. I would be in favor of simply removing the
wildcard feature with a note in the release notes, unless someone pops
up to argue that it's more widely-used than we think and it should be
deprecated instead, in which case I think a normal depreca
deoff for that (frankly somewhat
ridiculous - IE6 is how many years old now?) edge case to continue to
hold the rest of the community hostage.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
have a look at ticket 14082 [2].
>
> If not, ah well. :-)
Thanks for the ticket reviews, and your work on the patch. Committed in
r16334 [1]
Carl
[1] https://code.djangoproject.com/changeset/16334
--
You received this message because you are subscribed to the Google Groups
"Django developers&
at code as library code, so I actually find it
preferable if the bulk of the code lives outside the management.commands
namespace, and is just imported and used by the management command. This
can also encourage a separation of responsibilities that makes testing
easier.
Carl
--
You received
d to any specific mention of this ruling in the patch, and
certainly opposed to any attempt in the documentation to define which
Django-set cookies are "essential" and which require user consent -
legal advice related to particular legal jurisdictions is WAY out of
scope for Django's docume
g func could do it--
> after constructing the template, the loader would annotate with
> origin.
>
> It seems obviously useful, so I think there must be a good reason it
> wasn't already done. :)
Looking at the code only briefly, it seems pretty reasonable to me.
Carl
--
You rec
e this into the {% form %}
(nee {% renderform %}) tag with some syntactical modifiers, e.g.:
{% form "myfield:errors" %}
Or even with a filter?
{% form "myfield"|fielderrors %}
But it may be cleaner just to do it as a separate tag.
Carl
--
You received this message because y
ier tags.
Given that this is something you'd likely only do once in your project,
not over and over again, I think the downside of typing the extra tag is
minimal.
> After all I have no objections against the {% formdefaults %} proposal and
> would be happy implementing it if thats your pre
Hi Luke,
On 05/23/2011 05:14 PM, Luke Plant wrote:
> On 23/05/11 18:33, Carl Meyer wrote:
>>> It is not nearly as invasive as the other changes you suggested.
>>> However, it does fix the failing tests in my project (i.e. fixes
>>> csrf_protect), and leaves Templ
implementation
of csrf_protect and csrf_exempt. The response is still going to pass
through both of those decorators; a naive reader would be as likely to
assume "last-one-wins" as anything else. And I find it quite hard to
read, compared to just having a function available that takes th
SSES, marked decorator-only: if you
do, it would annotate, if you don't, it would run eagerly as it does
now.
Thoughts? Does something along these lines seem worth pursing as a
fix? Or am I off my rocker?
Carl
--
You received this message because you are subscribed to the Google Groups
Hi Jonathan,
On 05/23/2011 04:30 AM, Jonathan Slenders wrote:
> 1. Like Carl said, I always prefer template tags which alter the
> context to create a scope. (I hate {% url ... as varname %})
>
> {% form "table" %}
> {% renderform my_form %}
> {% endform %}
uot;formfields" dictionary in the template context (via context
processor), so you have an easy way to pass in actual Field subclasses
and don't need any special "constant form" for that. (Same for the
"widgets" dictionary and the first argument; for that argument using
On 05/22/2011 07:22 PM, Russell Keith-Magee wrote:
> On Mon, May 23, 2011 at 6:21 AM, Carl Meyer <c...@oddbird.net> wrote:
>> Just had a quick conversation with Gregor and Chris Beaven on IRC;
>> based on a comment of Chris', we discussed the possibility of ditching
>&g
this; it could cause some nasty bugs if apps are stomping on each
others' names, or even built-in field/widget names. Maybe requiring an
additional context processor for any third-party app that wants to
provide custom fields and widgets into the template context isn't such a
bad idea after all.
ecified that way, with minimal
boilerplate, we don't need the global-context-modifying version of
formlayout either.
Not sure if Gregor was entirely convinced, but I think I'd probably
lean towards doing it this way.
Carl
--
You received this message because you are subscribed to the Google Group
we don't have any use case in mind
for (unless making this split makes the code easier to read and
understand). This is something that most likely could easily be done
later, if we find we need it.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django
ficant ways (because it changes the order things happen in).
Not sure what that implies, except that maybe decorator_from_middleware
and the pattern it encourages is ultimately at least as problematic as
TemplateResponse...
Carl
--
You received this message because you are subscribed to the G
ate hearing them. My main objective is to find the most direct
> path to something that you guys will find acceptable. Thanks.
Thanks for contributing!
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
e still there is just a
matter of historical inertia, and that nobody's been sufficiently
motivated to deal with the backwards-compatibility difficulties to
change it.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
above, or what people would add as core requirements.
Carl
--
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
dj
t mind leaving get_profile() around, I guess, but IMO the best
argument that can be made for that is "it's useless but mostly harmless,
and it's not worth making people change their code to remove it." I'll
continue to recommend in IRC and elsewhere that people avoid using it.
Carl
--
You
rm = MyModelForm(request.POST or None)
try:
obj = form.validate()
except ValidationError:
pass
else:
obj.save()
return redirect(obj)
return render(request, "foo.html", {"form": form})
Carl
--
You received this message because you are su
res try-except handling for every form-handling view. I don't
necessarily consider that a problem: there's something that feels right
about exception-handling, rather than if-else clauses, as the idiom for
managing form validation errors. (Clearly it has something to recommend
it, since that's already the
how tie the errors to the form fields, if so desired
>...
This ends up being pretty similar to Johannes' idea - I'll reply to his,
feel free to note any differences you think are important.
Carl
--
You received this message because you are subscribed to the Google Groups
"Djang
cted that full
model validation is run, and any tweaks to the model must be made
before validation rather than after.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop
, I missed this somehow earlier. I agree with you that this is
another example of why attempting to do partial model validation is
simply broken. I think the context manager proposal (which I've posted
in a new thread) does fix this case as well, and I'd be happy for your
comments on it.
C
thread
I'm happy to continue conversation on that, but I'll do it in the other
thread for clarity.
Thanks,
Carl
--
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.
T
? Use cases
this doesn't handle?
Thanks,
Carl
--
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-develop
tten post about exactly that to begin
a new thread - should be up shortly!
Carl
--
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 thi
e fix?
I'm committed to having these tickets closed one way or another before
Django 1.4 is released (and neither fix here would be a candidate for
backporting to a 1.3.X release anyway), so let's focus on making the
best fix we can. If the ideas we have in mind for that turn out to be
unworkable for some r
ing gears. In terms of what's best for Django, I think Alex is
right on this one, so I plan to just work on the better fix rather than
committing the current patch on #13091.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
log queries and see that log in console will greatly
improve immediate awareness of O(n) query situations.
Carl
--
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.
But if you want
it in core, a battle-tested external implementation is a pretty good
place to start the conversation.
Carl
--
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@googlegroup
thanks. I think this behavior change only needs to be described
in one place (the validate_unique docs), but the text at the former link
is actually inaccurate ever since model validation - it should be
updated to mention that unique_together is also checked by model
validation, with a link to the
o.
> While we are on the subject of new idioms, I am curious as to what
> might be wrong with this slight amendment to the current idiom:
>
> form = ModelForm(data)
> form.instance.excluded_field = programatic_data
> if form.is_valid():
> form.save()
Nothing's wrong with th
do - and I'm also feeling more and more like
the "use_for_related_fields" Manager class attribute is an ugly hack,
and open to looking at patches to replace it with per-relation override
of the default manager-selection.
Carl
--
You received this message because you are subscr
s both to the manager and its
returned queryset, and I'd like to have the added method(s) available
everywhere, including on related-object managers.
I haven't yet had a case where I wanted a manager to be the default
manager for normal operation, but wanted to specify
use_for_related_fields=F
to allow you to complete/tweak the model instance
before full validation is run. Seems like this would solve your problem?
Carl
--
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@goog
ver, I do think that a modification is warranted to
> resolve the underlying error of the above-listed tickets, as well as
> my own.
Yes, I agree that the current patch on #13091 is too aggressive.
Carl
--
You received this message because you are subscribed to the Google Groups
it yourself before marking Accepted?
Carl
--
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
trolled so I can commit the "manual test"
setup for a given bug (in a branch named with the ticket number) in case
I need it later for working on the bug.
HTH,
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
On 04/20/2011 04:27 PM, Alex Gaynor wrote:
> Consider me in on the 5-1 offer.
Same here.
Carl
--
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 uns
have blocked the release"
spirit of the proposal.
Carl
--
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
up on
IRC (carljm) or here if you have questions working on the patch. I made
some additional comments on the ticket. Thanks!
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-devel
to do backports (which I also agree I haven't found
problematic).
Carl
--
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
call into `Field.formfield`?
In theory, yes, although a brief look at the relevant code doesn't
suggest any obvious clean fixes to my mind.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send emai
feature (given that the
> bug was discovered only now). And thus, explicitness might actually
> be a good idea.
Do you have real-world use-cases in mind that require per-relation
manager configuration? I can't think of any uses I've run across that
weren't workable with a single default
elated_fields would be
neither True nor False, so to counterbalance that I'd want a pretty
strong case for why it's the best option.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
pat with existing subclasses, but we could
respect it if set directly as an instance attribute:
objects = MyCustomManager()
objects.use_for_related_fields = True
I may open that as a separate ticket.
Carl
--
You received this message because you are subscribed to the Google Groups
lated_fields. For example,
people might suddenly start getting ObjectNotFound from a OneToOneField
descriptor where previously they got the "hidden-by-default-manager"
object back. So I think we could only do that with some kind of
deprecation path for the current default of False.
don't see any evidence of a bug in Django here (we've got
a pretty good test suite for filter traversal and inheritance), so this
thread should move to django-users.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To po
g loggers
> would suffice.
That might be reasonable as well - I'm interested to hear Russell speak
to that, as he did the logging work. I still think making setup_environ
non-lazy is a reasonable change that will address a broader range of
problems.
Carl
--
You received this message because
t will be
translated once when your models.py is imported and not translated to
the appropriate locale for each user.
Carl
[1] see
http://docs.djangoproject.com/en/1.3/topics/i18n/internationalization/#lazy-translation
--
You received this message because you are subscribed to the Google Groups
&qu
enerally work around it if you need to by just
not making your custom manager the default one), but it is inconsistent,
hard to explain, and means "use_for_related_fields" is quite
misleadingly named.
Input welcome,
Carl
[1]
http://docs.djangoproject.com/en/dev/topics/db/managers/#se
n issue for setup_environ, because it takes the module
as parameter and actually sets DJANGO_SETTINGS_MODULE. So I don't think
there would be any harm (and there would be significant predictability
benefit) in having setup_environ trigger the actual loading of settings
immediately.
Carl
--
You recei
, "buyer_partner" is the name you would use to traverse from the
partner targeted by the "partner" FK back to the Buyer containing that
FK. To traverse from the Buyer to its partner, you would just use
"partner" (the name of the FK) not "buyer_partner" (the
think your proposal could get there fairly easily --
all that's needed is for the mapping to and from the Python
representation to be customizable by a CompositeField subclass. So a
namedtuple representation is a sane default, but a GFK implementation
could override that to map to and from ac
Hi Mikhail,
On 04/01/2011 05:09 PM, Mikhail Korobov wrote:
> Hi Carl and Gregor,
>
> On 2 апр, 01:17, Carl Meyer <c...@oddbird.net> wrote:
>>
>>> 3. The designers I worked with are often interested on adding custom css
>>> class
>>>o
is running in germany during the time that I will
> work on the project. However based on my experience with last years of
> university I think that I can provide about 30 hours per week for work on the
> project, discussing questions and suggestions on the mailing list and so on.
>
&g
chives, which I haven't done, and is a reasonable
thing to expect a GSoC applicant to do - but it seems to me that if any
core devs have a clear idea that the approach in the #3011 tickets is
not workable, it would probably be worthwhile Trac gardening to say so
(and briefly why) on the ticket itself.
to get instances from all subclasses at once then
> this is a viable solution, FWIW.
Yup.
Carl
--
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
st of
subclasses is (less than) half the battle; the trickier part is giving
the ORM the capability to do UNION queries on similar tables, so you can
get results from multiple tables in a single QuerySet.
Carl
--
You received this message because you are subscribed to the Google Groups
"
ing some unions, but would still fit the use case
> pretty well, I think.
I'd certainly be intrigued to look at a patch that implemented that.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, sen
t the current markup in Django works fine and
is already valid HTML5, I don't see why we would want to do this, short
of possibly in a full admin redesign later on.
My understanding is that Luke is proposing 1 & 2, but not 3 - and I
agree with that. Like others, I'm interested in hearing
n your projects, it's not hard
to do so.
Carl
--
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+uns
r rather than later.
Carl
--
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...@googl
On 03/28/2011 02:33 AM, Russell Keith-Magee wrote:
> As with the other thread on Trac changes -- I agree this is worth
> doing, but would like to hear some other core dev voices before making
> any changes.
These changes look to me like a gain in sanity on every front. +1
Carl
to restore
it with a post-save signal handler. You can make your own trivial
subclass of FileField that attaches this post-save handler in the
contribute_to_class method: that's precisely what FileField used to do.
Carl
--
You received this message because you are subscribed to the Google Group
ink
is a pretty good compromise: keep the error message the same in all
cases, but append "or you don't have permission to log in here." so it
actually covers the possible cases and isn't quite so misleading. I
think that change should be uncontroversial.
Carl
--
You received
de the needed extension points.
This sounds reasonable to me.
> I'll post some updates here and on the ticket, in the meantime I'm
> open to comments and suggestions.
Great! Thanks for working on this.
Carl
--
You received this message because you are subscribed to the Google Groups
d values in the main
settings.py, and can actually modify them (i.e. append to
MIDDLEWARE_CLASSES or whatnot). With an import this is not possible.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send em
On 03/21/2011 09:14 AM, daonb wrote:
> On Mar 20, 4:49 am, Carl Meyer <c...@oddbird.net> wrote:
>> Those last five characters in "get_context_data" actually serve quite a
>> useful purpose, IMO. They clarify that the return value is just the data
>>
he return value is just the data
that will go into building a context (a dictionary), as opposed to being
the Context or RequestContext object itself, which is what I'd expect
from a method named "get_context".
Carl
--
You received this message because you are subscribed to the Google
em is that they
allow reusable code to access the user profile, but I'm not sure what
reusable code is going to usefully do with a custom profile model when
it has no idea what properties it has.
Just use OneToOneField and the regular ORM access descriptors, and you
can have as many "user prof
layout, as I think it's highly idiosyncratic and
dependent on the nature of the project. But I am strongly -1 on any
proposal to introduce any more sys.path-mangling anywhere in Django. I'm
eager to remove the bit that is already there.
Carl
--
You received this message because you are subscribed t
501 - 600 of 728 matches
Mail list logo
