in contrib.staticfiles.
Maybe there's a documentation patch you're thinking of to direct people
more clearly to StaticLiveServerTestCase? Currently it looks like that
only happens in the "changed in Django 1.7" note at the bottom of that
section.
Carl
signature.asc
Description: OpenPGP digital signature
ssets in
Django. It probably is the most commonly-used way, but it is not
required. It is possible to write a fully-functional Django project that
uses static assets without using contrib.staticfiles to manage them.
IMO this is good enough reason for both LiveServerTestCase and
StaticLiveServerTestCase
m,
> just so I can validate its contents.
>
> Another approach to validating an unbound form appears to be to extract
> "value" from the model instance instead of cleaned_data, and this
> bypasses the management form issue, so I'm experimenting with that
> approach.
>
> It seems to me that there would be value in being officially able to
> validate unbound forms, and it might not be hard to implement.
Yes, I see the use case; not sure what the API would look like for it.
Carl
signature.asc
Description: OpenPGP digital signature
I think
this is an unusual use case, and I'm not sure support for it belongs in
core. It would be interesting to experiment with something to make
filefields less painful when validation fails, but that can be a
third-party project first I think.
Carl
signature.asc
Description: OpenPGP digital signature
ommon python pattern that fits well with this usage.
Backwards-incompatible (and generally problematic) for any model with a
field named 'default'.
Adding special keyword arguments to functions that currently take
arbitrary filters as kwargs is basically a non-starter.
Carl
--
You rec
ssible (that is, a single-file settings.py) and not try to provide all
possible ways of handling multiple-deployment settings.
Carl
signature.asc
Description: OpenPGP digital signature
would not be a major problem.
> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are we
>ready for this?
I think so, yes.
Carl
signature.asc
Description: OpenPGP digital signature
on, such
that we can use it internally in Django performance-sensitive template
renderings (i.e. form widgets). If we don't achieve even that in the
first iteration, then we haven't achieved much that isn't already doable
via third-party adapters such as jingo or django-jinja.
Carl
signature.asc
Description: OpenPGP digital signature
escape-by-default, it's a configuration parameter
when creating a template environment. Obviously Django would set it to
True. So this is not an issue.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this
er to show any improvements, we must have timings for the
> current tool.
>
> Can people who've suffered slowness please donate fragments of template
> they've found particularly slow?
Have a look through the comments of
https://code.djangoproject.com/ticket/15667
Carl
--
You
On 02/11/2014 12:17 PM, Carl Meyer wrote:
> On 02/11/2014 12:11 PM, Val Neekman wrote:
>> Is the following statement still valid?
>>
>> "Any handlers that listen to this signal need to be *written* in a
>> particular place: a management module in one
ng it should be
guaranteed that by the time a management command runs all models of all
installed apps are imported.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from
, but would also allow long term backwards
> compatibility, as the Django template language could be maintained long
> term, even if it is dropped as an officially supported option by Django
> itself.
This is basically the same approach that I would favor, although I would
immediately make Jinja2
in some
databases.
See the implementation of `Field.db_type()` and the `data_types` class
attribute on the various DatabaseCreation classes in the db backends.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from
.
I don't think there's a reason to require the argument; if `None` is a
valid value for the argument, then clearly it is semantically optional,
so give it a default of `None` and make it actually optional.
Carl
--
You received this message because you are subscribed to the Google Grou
to connect via https://webchat.freenode.net/ but not through
> my
> IRC client.
FWIW, it seems that NickServ is also nonfunctional/unresponsive due to
the DDOS, which means that even if you can connect (and I have been able
to connect via IRC client), you won't be able to get in
e" right now, and then waiting until
1.7 to do your migration. Or if you really want to do them in a single
change to your codebase, you just do it now under Django 1.5 or 1.6
using South.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django deve
ence. Why not add it for one release without
deprecation, so we can find out whether it is actually problematic in
practice? Then we still have the option of deprecating it if it is a
problem, but we haven't forced ourselves into a corner.
Carl
--
You received this message because you are subs
quired_app_config we are in a sense
> changing the configuration of an app that the user has in their
> settings, therefore a visible warning is justified. However, I'm +0 on
> doing this over an extra release cycle]
I don't think that "in a sense changing the configuration
On 01/20/2014 01:01 PM, Carl Meyer wrote:
>>> 3a) As for 3, but use a flag on the AppConfig subclass that marks
>>> it as "use me as the default". If there are more than one AppConfig
>>> objects in an apps module that has the 'use as default" f
o not mark
> itself as default. -1
I don't see what advantage this has over (3) - it just allows another
failure mode. -0.
>> 3b) As for 3, but use the first class discovered that is a subclass
>> of AppConfig. Actually identifying the "first" is a bit of an
>> implem
On 01/20/2014 12:22 PM, Aymeric Augustin wrote:
> On 20 janv. 2014, at 18:36, Carl Meyer wrote:
>
>> I very much hope
>> that moving the admin autodiscovery to the admin AppConfig still allows
>> some reasonable path to opt-out of autodiscover - perhaps by subclassin
is discussion, though - if "subclass
the AppConfig and override something" works to opt out of autodiscover,
then I still wouldn't see this as a "good reason for not using an
AppConfig."
Carl
--
You received this message because you are subscribed to the Google Groups
&
On 01/18/2014 01:19 PM, Anssi Kääriäinen wrote:
> On Saturday, January 18, 2014 9:02:41 PM UTC+2, Aymeric Augustin wrote:
>
> On 18 janv. 2014, at 19:50, Carl Meyer > wrote:
>
> > Those interested in this feature may find django-transaction-hooks
> [1]
more
likely, not bother to handle.)
Testing and feedback welcome. If this becomes widely used and seems to fill
a need, I think there is a chance it could become part of Django core. (See
#21803.)
Carl
[1] https://github.com/carljm/django-transaction-hooks
--
You received this message be
ve a patch but have the "patch needs improvement" flag - there are a
lot of these and they are in need of contributor love, too! Some tickets
are marked this way when what they really need is a whole new approach,
so you may still be largely writing a patch from scratch in this case.)
Carl
signature.asc
Description: OpenPGP digital signature
area"; I'd support changing that paragraph in our docs (though it
shouldn't be relevant anymore once you've done one comprehensive pass
and integrated an automated flake8 in the PR process).
Carl
--
You received this message because you are subscribed to the Google Groups
"
On 10/01/2013 06:36 AM, Ivan Kharlamov wrote:
> On 09/27/2013 09:01 PM, Carl Meyer wrote:
>> On 09/27/2013 03:07 AM, Ivan Kharlamov wrote:
> Thank you for considering a fix!
>
> Personally, I'd prefer a solution proposed by Shai, which is (5).
I commented in my reply to Sh
Hi Shai,
On 09/27/2013 05:42 PM, Shai Berger wrote:
> On Friday 27 September 2013 20:01:00 Carl Meyer wrote:
>> 3) A first-run warning that can be turned off (and presumably would be
>> off by default in new projects). The obvious mechanism for turning it
>> off would be
om settings.base
import *", or using local_settings.py.
(Since I don't think Django core is going to take any steps to endorse
any particular approach to handling settings anytime soon, I think this
discussion is really off-topic and should move somewhere else. I should
have considere
within the CWD, doctests) and warns you if it finds any. This would be a
fair chunk of code that would be easy to get wrong, and I think it's
really too late to add it to 1.6. It would also slow down test-running
unnecessarily on every run.
So, like I said, a bunch of bad options. Which i
on into a production instance. The only two solutions I've
used for that are local_settings.py and env vars, and having used both
I'm much happier with env vars. (Even with env vars, I track them in a
simple shell file in a separate, private deployment VCS repo.)
Carl
--
You received this
Hi Christophe,
On 09/26/2013 04:28 PM, Christophe Pettus wrote:
> On Sep 26, 2013, at 2:32 PM, Carl Meyer wrote:
>> We already provide the on_delete=DO_NOTHING option for people who
>> want to push cascade handling to the database.
>
> It's better than the previou
o take a stab at this, but my feeling is that it's not
worth it; better for those people who actually need the efficiency of
db-level cascades to opt into those changes explicitly via
on_delete=DO_NOTHING.
Carl
--
You received this message because you are subscribed to the Google Groups
&
ves a mention here before a decision is
made.
Any thoughts or arguments that haven't already been presented on the ticket?
Carl
[1] https://code.djangoproject.com/ticket/21127
--
You received this message because you are subscribed to the Google Groups
"Django developers" g
y adjusted to it. I think any
proposal to build a more complex system into Django core needs to
clearly explain what it allows you to do better than the current API.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To un
; numerous other contributors!
>
> Now let me introduce you the framework.
I haven't had the time this summer to keep up with your progress, but
based on your summary here, this looks really excellent! Thanks for your
work.
Carl
--
You received this message because you are su
g that, but I doubt it was the reason for the delay, more
likely just didn't catch anyone's attention for review and merge. If
someone had sat down to review it and been blocked by it not merging
cleanly, they'd have commented to that effect on the ticket.
Thanks again for the patch
Case in core just serves from STATIC_ROOT.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.co
prefixed method as public API, and
that is potentially backwards-incompatible for anyone who has defined
their own .clone() method on a custom QuerySet subclass.
The alternative would be to recommend the use of qs.all(), which is in
fact already an alias for qs._clone(). In that case perhaps the CB
On 07/10/2013 05:40 PM, Carl Meyer wrote:
>> I'm not sure I completely agree with Carl that is breaks correspondence
>> -- after all, m2m fields don't correlate to a field, either. However, in
>> the absence of a built-in migrations framework, I suspect a O2M field
&g
ut with others as well. To that end, I have a
> certain sympathy for the request.
>
> I'm not sure I completely agree with Carl that is breaks correspondence
> -- after all, m2m fields don't correlate to a field, either. However, in
> the absence of a built-in migrations
ad
of an exception whose meaning may be unclear. In this case it seems like
the opposite: the specific exception, which may be useful, is
suppressed, and no additional info is provided beyond "some exception
was raised". So personally I would be fine with removing the try/except
here.
I g
think the existing resolution is correct. This seems like a perfect
case for a third-party field class. I don't think the need to represent
MAC addresses in the database is common enough in web development to
warrant inclusion in Django core.
Carl
--
You received this message because you are su
t that strong; it's just a
new way to spell the exact equivalent of a ForeignKey.
That said, I'm pretty sure you could code this up outside of core, if you'd
like to experiment with it.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django
e other and then
there are two different management commands?
Interested in your thoughts,
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django
d expect (whereas with South now, and with option 2, syncdb doesn't
> do enough).
I much prefer option 3; I think a deprecation path for syncdb is fine.
It's always been mis-named anyway, since it doesn't really sync.
Carl
--
You received this message because you are
olves the third-party-backend problem; said backend should
have its own tests as needed, and Django's tests for backend-specific
behavior should be skipped under any unrecognized backend.
Carl
signature.asc
Description: OpenPGP digital signature
I'm not sure what you mean by "Shipping OL actually should be optional."
We either ship it (and link to our own version) or we don't; how could
it be optional? I certainly don't think a toggle setting or anything is
warranted here.
Carl
signature.asc
Description: OpenPGP digital signature
s _should_ be interpreted as relative to wherever you are
running the tests from.
But it should be fixed in the
test_runner.test_discover_runner.DiscoverRunnerTest.test_file_path test - that
test apparently needs to isolate itself better by setting the CWD for the
duration of the test, or some
ttest itself even runs the tests when specified that way, given the lack of
__init__.py.
That said, if this turns out to to be something that trips a lot of people up,
it would be trivial to add a special-case in runtests.py to look for and remove
the initial "tests." in provided test lab
ty project and bring it back for
consideration in the future if it's demonstrated usefulness and wide use.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from i
a "needsinfo" closing (the issues are always around "wontfix"
closings). Making the change you are suggesting means introducing a new
tracker-gardening task, "closing old needsinfo tickets." Needsinfo was
added as a "closed" state precisely in order
Hi Florian,
On May 11, 2013, at 7:51 AM, Florian Apolloner wrote:
> Hi Carl,
>
> before I read all the tickets etc; why does runtests.py not use the
> TEST_RUNNER from settings.py (see
> https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149
I merged this patch tonight. Thanks to everyone who contributed! Now let's
see how the CI servers feel about it...
Carl
On Wednesday, May 8, 2013 5:00:56 PM UTC-4, Carl Meyer wrote:
>
> Preston Timmons and I have been working the last several weeks to get
> the test discovery
On Thursday, May 9, 2013 8:15:02 PM UTC-4, Russell Keith-Magee wrote:
> On Thu, May 9, 2013 at 11:30 PM, Carl Meyer
> > wrote:
>
>> Hi Russ,
>>
>> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote:
>> > Great work Carl and Preston! (And everyone else wh
t every time you run tests.
The second issue I'm not too concerned about. If the
previously-undiscovered tests pass, then there's not really a problem.
If they fail, it shouldn't be too hard to figure out what's going on.
Carl
--
You received this message because you are subscri
Hi Russ,
On 05/09/2013 04:51 AM, Russell Keith-Magee wrote:
> Great work Carl and Preston! (And everyone else who had a hand in the
> patch - I know this has been kicking around for a while now)
Thanks for the reminder; I should have mentioned that Mahdi Yusuf did
the initial draft patch,
o.
If necessary it wouldn't be at all hard to backport this code into
discover-runner so they are exactly the same; I haven't discussed this
with Jannis yet.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsu
apps are small/fast enough that you could just run the
whole app when bisecting instead of an individual TestCase, making this
a non-issue (since Django's test apps are top-level on sys.path, the
command to run a single app in Django's test suite is the same with the
new runner as with the
would make me sad to start
polluting it again with stuff that new projects generally shouldn't care
about, for solely legacy reasons.
Thoughts, questions, comments, code review and testing welcome! I'd like
to merge this on Friday (it's a bear to keep updated with trunk), so l
guess whether static validation will work.
It would be great to enumerate some common mistakes that the static
validation we're removing was supposed to catch, and see in how many of
those cases we can provide a similarly-helpful error at runtime
(hopefully with no performance cost in the
ting on a proposal.
> I still look forward to contributing to Django, but not as a GSoC student.
Glad to hear it - look forward to working with you as a contributor!
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
Hope this is helpful - good luck with your proposal!
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googleg
On 05/01/2013 11:04 AM, Carl Meyer wrote:
> I was the mentor for that GSoC project, and the reason for its failure
> is that the Django template language proved too slow for the
> template-based system we proposed for rendering form widgets and form
> layouts; form-rendering speed su
speed suffered by an order of magnitude in some
cases. There was another GSoC project that summer to speed up the
template language and for a time we'd hoped that would provide a
solution, but that project also failed in the end.
Carl
--
You received this message because you are subscribed to the
eve faster
releases we'll need to extend support longer, at least for certain
"long-term support" releases (a category which would probably be
retroactively applied to 1.4). We haven't hammered out the details of
the new policy yet, but I think it's safe to say that if we do relea
ode with the existing User model
there's little reason you'd want to switch over when upgrading to 1.5
(unless you are also adding new User-related features to your codebase).
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers&qu
Hi Emil,
On 04/17/2013 04:00 PM, Emil Stenström wrote:
> Carl Meyer skrev 2013-04-17 18:37:
>> Why not instead add a new block to base.html? So you'd change base.html
>> to have:
>>
>> {% block outer-content %}
>> {% block content %}{% endblock content %}
>
eed to
> remember to pass the right variable in the view instead, with the same
> problem as with copy-paste above.
>
> 5) Write a custom template tag that does what I want.
>
> Problem: I really don't know how to do this, and I haven't found someone
> that has wri
ntegrating twod.wsgi into Django core. Are there any
issues or problems with twod.wsgi that would be solved by integrating it
into core?
> So, do you agree that Django should have built-in support for running
> WSGI applications from inside views?
I'm inclined to agree with Aymeric
gest
subscribing to the django-core-mentorship mailing list and asking for
advice there: https://groups.google.com/group/django-core-mentorship
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and
d to add a few methods/attributes to
> HttpRequest to proxy the few things you need from request.META that are
> not headers, like REMOTE_ADDRESS and REMOTE_USER
As I mentioned above, I don't think we can dictate the "few things you
need from request.META" and make the rest inacce
think the API
> (or setting, etc.) should look like.
I think the answer to this is
https://code.djangoproject.com/ticket/17365 -- we are already planning
to replace the current app-based test discovery with the more standard
test discovery mechanism from unittest2, which will be able to find
tests a
he request and get the new behavior).
If that's the extent of the benefit (a new way for user code to get the
current site), then I don't see the reason to complicate the behavior of
the existing functions with new optional arguments; rather just add a
new and separate Site.objects.get_curr
unc" is a view function). I think it would
make more sense to leave the url-resolver alone, and build your system
around it; if you have a way to map a view-func plus args/kwargs to a
model instance (which is more or less what you'll need in any
implementation of this idea), then you can g
to the ORM. These are separate modules
that should not need to depend on one another, in either direction.
If you work on implementing this outside Django and find that you need
hooks that are not currently available, those hooks would making
interesting feature proposals for Django.
Carl
signature.asc
Description: OpenPGP digital signature
(including TransactionTestCase) can inherit from. I
> have experimentally written a SimpleTestCase based class for my needs,
> but I haven't yet tested it against the Django suite.
Sounds reasonable to me; those non-db-related helpers shouldn't need to
be on TransactionTestCase.
Car
fy a deprecation process for
Meta.widgets, IMO. Also, I think it's better for them to be indexed by
field name rather than type (formfield_overrides is indexed by type).
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
nt something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.
+1
Carl
--
You received th
Explicit is better than implicit.
+1.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To po
On Feb 20, 2013, at 6:25 PM, Ian Kelly wrote:
> On Feb 20, 2013 4:41 PM, "Carl Meyer" wrote:
> > On 02/20/2013 04:25 PM, Nick Phillips wrote:
> > >> There was extensive back-and-forth discussion of this in writing the
> > >> patch. The issue is that i
on't), they'd have to set it.
But in the end, this just splits the difference in a way that doesn't
help. For any given user, either it "just works" for local dev (and we
thus lose the awareness benefit you mentioned above), or we force you to
deal with it all the time (an
We've just released 1.3.7 and 1.4.5 to correct this packaging problem:
https://www.djangoproject.com/weblog/2013/feb/20/updated-releases-issued/
Thanks for reporting it!
Carl
On 02/19/2013 08:12 PM, Nick Popoff wrote:
> I downloaded Django 1.4.4 this evening and after switching to it
at from 1.5 onwards it will be an empty list?
>
> https://docs.djangoproject.com/en/1.4/ref/settings/#allowed-hosts
Yes, that's a good idea for the 1.3 and 1.4 docs, thanks for the
suggestion. Done.
Carl
--
You received this message because you are subscribed to the Google Groups
&q
#x27;*'] for the
duration of the test run, so if you want tests to exercise validation
you can just use the override_settings decorator to temporarily change
it for a test method or test case.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django develop
ctice) if we removed all mention of underscores in this document (or
even explicitly said that we don't generally use the underscore
convention), and clarified that back-compat applies only to documented
modules, classes, methods, and attributes.
Thoughts?
Carl
--
You received this message
ean the connection is broken (e.g.
IntegrityError). If some codebase makes heavy use of algorithms like
get_or_create that rely on a correctly-handled IntegrityError, they
shouldn't need to pay the cost of the ping more frequently.
Carl
--
You received this message because you are subscr
nything related to
DBAPI drivers and error conditions does :/
I tried to dig for the origins of the current MySQL behavior to see if
that would illuminate such a case, but that code goes way back into the
mists of ancient history (specifically, merger of the magic-removal
branch), beyond which the g
same point when Django will currently close your
connection for you). So the effect with CONN_MAX_AGE=0 is really not
distinguishable from what you get currently.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscr
a cheap and
> easy performance improvement. Let's get it in.
+1 from me too. Similar experience on Heroku (which is of course also
AWS), persistent DB connections via django-postgrespool were a quick and
easy win to save a significant chunk of response time. I don't see any
reason Django
act an implementation of reusing SQLAlchemy's connection
pool with Django (via DatabaseWrapper subclassing):
https://github.com/kennethreitz/django-postgrespool/
I have this in production for several months with no issues, so the
concept certainly works.
Carl
signature.asc
Description: OpenPGP digital signature
ko
> templates. That would be huge advantage over existing solutions like
> django-mako. I think that could be a good idea for GSoC this year. Do
> you think so?
This definitely would bring some value; it's the best rationale I see
for refactoring the template engine.
C
complete the ticket? I hope
> that we can make Django better.
The approach you're taking is very much the approach I'd envisioned when
I opened the ticket, and it seems like you're thinking through all the
potential issues carefully; I don't see any obvious problems in your
approach.
As I said above, I've since felt like this problem is perhaps more work
than it is worth at this point in Django's evolution (for myself,
anyway), but I won't speak for anyone else on that score, others may
feel differently.
Carl
signature.asc
Description: OpenPGP digital signature
ll_ you want is to
know whether there are any matching rows; you're not going to do
anything with the rows themselves.
When the existence-check is just a path on the way to the "real" use of
the queryset, you can be quick and implicit; when the existence check is
all that you care abo
mmediately clear to me how
to do that without introducing some unsavory widget-type-checking into
BoundField. So I think the right fix here may take some thought.
I searched the bug-tracker at code.djangoproject.com and didn't find an
existing bug for this - do you mind filing a bug for it?
Thanks!
Carl
gh the main duplication you'd want to save is in
tox.ini, and you'd need to write some extra code to help tox "inherit"
config files before you'd be able to save any redundancy there anyway.
Carl
--
You received this message because you are subscribed to the Google Gr
ge.
That's not checking whether the file has been modified, that's checking
whether the same source file was previously copied in the same
collectstatic run (due to overlapping/duplicate file sources of some kind).
The check for modification date is up on line 234 in the delete_file
method,
only irritating bit is that the Django admin implements its own
logout via GET, so you have to subclass AdminSite to fix that if you're
using the admin.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
haven't looked into how to do it now - but
that still seems to me like basically the right approach.
Carl
[1] Of course, the same could be said for "manage.py shell" itself,
which, in Django 1.4 at least, is little more than a shortcut for
setting DJANGO_SETTINGS_MODULE and runni
301 - 400 of 768 matches
Mail list logo
