arlier in the thread, making Python programmers deal with
long lines seems like some special form of torture ;)
Cheers,
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 f
o do
a query:
for author in Author.objects.all():
for book in author.books.all():
book.author
There wouldn't be any action-at-a-distance with other Book instances.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigm
uot;, as this namespaces the project better and
avoids potential top-level namespace clashes with generic names like
"settings" and "urls". However, it's easy enough to adjust the layout
and imports for your own project to eliminate that project package and
just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 08:25 AM, Chris Wilson wrote:
> On Fri, 10 Feb 2012, Carl Meyer wrote:
>>> Is there any reason not to drop the project name part of
>>> DJANGO_SETTINGS_MODULE and ROOT_URLCONF, to reduce the risk of
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2012 08:47 AM, Adam "Cezar" Jenkins wrote:
> On Fri, Feb 10, 2012 at 9:50 AM, Carl Meyer <c...@oddbird.net
> <mailto:c...@oddbird.net>> wrote:
>
> "import .module"
>
>
> Not arguin
is acceptable, can core devs please
> accept the patch?
Patches without tests won't be committed. There are many existing
examples of tests that test form rendering and HTML output; for
instance, most of the tests in regressiontests/forms/.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v
he ticket to a github branch or pull request is fine in lieu
of an uploaded patch. I don't know that this is formally documented
anywhere, but it's been the actual practice for a year or more now.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozil
is used in a method of the
decorated class, because the name given as the first argument to super()
will actually refer to the subclass at runtime. This problem, and
alternative options, were discussed extensively in a thread here a few
months ago.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v
elated is probably
monitoring their SQL queries, and is likely to notice the extra SQL
queries pretty quickly.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9BJeUACgkQ8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/19/2012 09:40 AM, Carl Meyer wrote:
> On 02/18/2012 05:37 AM, Anssi Kääriäinen wrote:
>> The second one is about .iterator() and .prefetch_related()
>> interoperability. They are mutually exclusive (you need to fetch all
>&g
ent for wontfix decisions being reversed, but this
isn't one. The lexing bug revealed in #3888 that caused multiline {# #}
to sorta kinda work in a broken way had its own ticket opened (#4164)
and was fixed. In any recent Django, including 1.3.1 and 1.4 beta,
multiline {# #} does not work at all.
Carl
---
y.originator|get_really_full_name:"mailto"
> link=entry.get_metadata.link task_id=entry.task.id
> process_name=entry.task.process_class|contenttype_name %}
Acknowledged. That would be a lot nicer split across multiple lines.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU
and perhaps one with a stronger
opinion on the issue. So posting here was the right thing to do - now
the right thing is probably to wait for a bit.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAY
ther than later, but it really depends on exactly how much
harder that path is.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9CugQACgkQ8W4rlRKtE2fr6wCg2/cXMn/bHL/p6Cg5YDzZmPNe
AasAoKWeKEnD
the value to
> ``datetime.now()`` as it does when you use ``Model.save``.
There is already a ticket for this (#15566).
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmai
no idea. You could stick some "pdb.set_trace()" into the copy
function and see where it's getting those files from, I guess.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECA
angoproject.com, ideally with a patch containing a failing test
case integrated into Django's own test suite.
Thanks for the report!
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9D
is dedicated exclusively to discussions about
> development of Django.
It seems to me you may have mis-read Tom's message. It seems perfectly
on-topic to me; he's not asking how to fix his problem, he's asking
about the design of BaseModelFormSet itself.
Carl
-BEGIN PGP SIGNATURE-
Versio
et along these lines but didn't find anything.
> I'm not an experienced django contributor, so I'm posting here hoping
> for some feedback to verify that I'm on the right track (or not), i.e.
> is this something that I ought to create a ticket for (and some tests
> and a patch)?
I think
t;body"
attribute is the primary, and simplest, way to just get the full body of
the response. "read" is present only so that a request can be treated
like a file object.
Carl
signature.asc
Description: OpenPGP digital signature
l counts: the method is poorly named, it can't be
changed now (and is not worth a deprecation process), but the docs
should be less misleading. Can you file a ticket for this?
Carl
signature.asc
Description: OpenPGP digital signature
will return True.
But request.user is far from the only circumstance in which you might
have a User instance. And all User instances have this method, not just
the one attached to a request by the auth middleware. The method name is
only accurate in the latter case.
Carl
signature.asc
Descript
r it's marginally better or not -
there's no way it's enough better to justify the massive
backwards-incompatible change for everyone currently using a request as
a file-like object.
Carl
signature.asc
Description: OpenPGP digital signature
e-line restriction was the last
time I had to work on internationalized templates using blocktrans. The
presented use cases have me thoroughly convinced that this is an
unreasonable restriction on template authors, and I'd be +1 on lifting it.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU
l reporter didn't realize the problem
was specifically related to use of MySQL (and, it seems, the MySQL GIS
backend). Thanks for the additional information!
Carl
signature.asc
Description: OpenPGP digital signature
ady for Checkin. If you'd like to see it in
(post 1.4 at this point, of course), feel free to do that!
Carl
signature.asc
Description: OpenPGP digital signature
by
only sending the values of certain fields to the database at all,
something that your proposed code does not do.
Carl
signature.asc
Description: OpenPGP digital signature
n be done externally).
So I appreciate the offer, but I don't think the time is right to add
this to Django core.
Carl
signature.asc
Description: OpenPGP digital signature
Łukasz; I support PEP 414 in general, but I'm not at all
convinced that it makes sense to use it for Django's port, given that we
already have a working port using the unicode_literals approach.
Carl
signature.asc
Description: OpenPGP digital signature
parameter.
This may tip the scales towards considering this not worth doing,
depending what compelling use cases can be presented.
Feel free to file a bug for this and it can be revisited after 1.4 is
released.
Carl
signature.asc
Description: OpenPGP digital signature
LTS will include Python 3.2, and
it won't be possible to make use of PEP 314 on Python 3.2 without
install-time-transformation hacks, is a strong argument in favor of
sticking with a working unicode_literals port rather than reworking it
to use PEP 314.
Carl
signature.asc
Description: OpenPGP digital signature
s their own session implementation or
cookie-based authentication of some sort.
Practically speaking, I think this might be ok and would cover the
majority of real cases. But at the very least it means that this
decorator should live in contrib.sessions, not in the core CSRF code.
Carl
signatur
ion check? Have you considered the
effects this would have on every user of contrib.auth (both those who do
and don't run the schema migration)? And the effect on Django
development (needing to run the tests with both an "old" and "new" table
to ensure that the backwards-compati
r and throw a form validation warning for those that
> didn't.
Catching the database error won't work - some databases won't raise an
error, they'll just silently truncate the value, potentially leading to
all sorts of nasty data corruption problems and confusing bugs down the
road.
Carl
sign
e allowing execution to continue you need to use
> warnings.warn().
>
> As things stand you are essentially implementing the behaviour for both
> 1.4 *and* 1.5!
Indeed; thanks for the report. I've now fixed it to use warnings.warn,
as it should have originally.
Carl
signature.asc
Description: OpenPGP digital signature
ards helping make one of those latter two things happen. But feel
free to work on a proposal to simply change the field length. If you can
provide a patch with a really compelling backwards-compatibility story,
my mind is certainly open to change.
Carl
signature.asc
Description: OpenPGP digital signature
nce to, and this cleans up their state so if the user should
happen to save one of them again after deleting it, the ORM will save it
as a new object rather than trying to re-save with the previous PK
(which can cause trouble in the common case of auto-increment PKs).
Carl
signature.asc
Description: OpenPGP digital signature
py files aren't
one of them.
In any case, importing anything from Django or your project in your
settings.py file is strongly discouraged, precisely because it tends to
lead to circular import problems.
Carl
signature.asc
Description: OpenPGP digital signature
rror is triggered on any import of django.db.*
Carl
signature.asc
Description: OpenPGP digital signature
lapping keys
via user.data (but writing is then allowed). In the common case of no
overlapping keys, of course, you don't have to worry about AUTH_PROFILES.
Carl
signature.asc
Description: OpenPGP digital signature
provide sample code demonstrating that this is
actually a problem, feel free to correct me!
Carl
signature.asc
Description: OpenPGP digital signature
going to suddenly prevent that approach, it just won't have any extra
sugar around it), or could provide an abstract base class that your user
model can inherit from that includes the needed fields, or could just
document "to use this app, your user model must have these fields: ..."
and l
, but is a much more invasive
change in the fundamental semantics of the signals framework, so I don't
think it's a realistic option.)
Carl
signature.asc
Description: OpenPGP digital signature
On 04/12/2012 10:52 AM, Jeremy Dunck wrote:
> On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer <c...@oddbird.net> wrote:
>> There's a discussion ongoing on ticket #18094
>> (https://code.djangoproject.com/ticket/18094) that has enough potential
>> back-compat implications
ctly tied to
database activity; they are tied to events on Python model objects. One
of the three signals under discussion is the pre/post_init signal, which
fires anytime a model instance is instantiated, even if no database
query or database change occurred.
Carl
signature.asc
Description: OpenPG
bole), it would be very helpful to know what
operating system and version you are using, and how you installed Django
1.4 (i.e the exact commands you used).
Thanks!
Carl
signature.asc
Description: OpenPGP digital signature
inheritance behavior to be opt-in when
connecting the signal handler. I think I'd like to see a deprecation
path so that eventually the inheritance behavior is the default, and you
have to opt out of it, as I think in most cases it's the desired behavior.
Carl
signature.asc
Description: OpenPGP digital signature
e can warn
people away from it and better advise them how to fix it.
Carl
signature.asc
Description: OpenPGP digital signature
dd a documentation warning about this. I think
the current warning is not quite in the right place, as it follows the
section on installing via a pth file or symbolic link. "setup.py
install" should not be used in that case, but not for reasons of the
above bug, rather simply because it's not
a different
> directory (django/conf/project_template_new), so that conflicts don't
> happen. It's a bit hacky but it would work.
No thanks.
Carl
signature.asc
Description: OpenPGP digital signature
Hi Alex,
On 04/12/2012 04:23 PM, Alex Ogier wrote:
> On Apr 12, 2012 6:16 PM, "Carl Meyer" <c...@oddbird.net
> <mailto:c...@oddbird.net>> wrote:
>> The correct solution is to warn people away from using installation
>> techniques in ways they were not int
t,
> and call it a day. Yes, Django can't make up for people who circumvent
> their package manager, but we can make it a lot easier to fix than
> sending newbies off into their system libraries armed with superuser
> permissions and "rm -rf".
Agreed.
Carl
signature.asc
Description: OpenPGP digital signature
. I'm experimenting right now with a patch to setup.py that
would print a loud warning to console if it detects an existing django/
directory in the target site-packages.
Carl
signature.asc
Description: OpenPGP digital signature
On 04/13/2012 08:33 AM, Carl Meyer wrote:
> Thanks Daniel. I'm experimenting right now with a patch to setup.py that
> would print a loud warning to console if it detects an existing django/
> directory in the target site-packages.
I've filed a pull request (https://github.com/django/dj
Hi Mikhail,
On 03/29/2012 01:31 PM, Mikhail Korobov wrote:
> GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form
> rendering) seems to get stuck because of performance issues.
>
> Question 1. Am I understand this correctly and the limiting factor is
> the template
Since it seems that the additional test-suite runtime from the new
default password hasher is enough to be a blocker for migrations to 1.4
in some cases, I've opened a ticket for documenting this workaround:
https://code.djangoproject.com/ticket/18157
Carl
signature.asc
Description: OpenPGP
com/ticket/18239) and will try to close it
this week unless someone else gets there first.
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
On 05/01/2012 12:45 AM, Vinay Sajip wrote:
On May 1, 2:19 am, Carl Meyer<c...@oddbird.net> wrote:
Good point. I think which of those happens now depends on whether a
motivated someone steps up to figure out how to convert the mirror to
use hg-git and source from Git, and then ma
) they are addressable concerns that
should be taken into account by someone working on a patch, they are not
a reason to close the ticket.
Carl
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email
of
anybody who prefers using it as a client, and mirroring in that
direction is pretty hard/impossible).
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 u
'merge --squash' your pull request
into a single commit on master, and credit you in the commit message."
Carl
*The third option, just doing regular merges of multiple-commit pull
requests, I don't think is nearly as bad as you make it out to be:
master would never actually be in a broken
a function view that returns a
TemplateResponse, and do the same types of tweaks using reusable decorators.
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
. Frankly, given how rarely I've seen this issue in practice with
South, I think this limitation is perfectly fine, and much, much, better
than introducing a whole new registration machinery and flattened
pseudo-namespace for Fields.
Carl
--
You received this message because you are subscribed
rs" is the wrong goal to begin
with - there's always a way to be insecure if you want. Our
responsibility as a framework is not to protect users, it's just to stop
actively encouraging them to do the wrong thing.
Carl
--
You received this message because you are subscribed to the
sue.
So while I favor option 3 for ModelForms themselves, I also think that
even if this discussion should end up rejecting that, we should still at
the very least require an explicit "fields" parameter for UpdateView.
Carl
--
You received this message because you are subscribed to the Goo
you don't have
> the fields in the HTML form, then the user can't edit the fields.
Yes, this is really at the root of the whole issue. I don't see a good
way to address it directly - but we can address it indirectly by
ensuring developers have to think explicitly about which fields their
Mod
-careful-forms), but it registers all
forms in a thread-local and performs the check in a middleware; that's
not something I think belongs in core Django.
> One problem would be excessive warnings if you went further and hand
> craft the HTML - does anyone do that?
Yes.
Carl
--
You received this
On 06/13/2012 06:12 PM, Doug Blank wrote:
> On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer <c...@oddbird.net> wrote:
>> On 06/13/2012 02:55 PM, Peter wrote:
>>> Can I throw in option 5:
>>>
>>> We leave ModelForms as they are, but emit a warning if you only
ner, rather than upstream
in one of the commonly-used Python test runners (such as unittest2), as
I'd rather move in the direction of less custom Django test-runner code
rather than more. But I guess that has to be balanced against the
convenience value of the feature.
Carl
--
You receive
n'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 running a python shell. I
it 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 group, send email to djang
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, which is called by b
n
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 Groups
"Django developers" group.
To post to this group,
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
--
You received this message because you are subscribed to the G
ant 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 about, you say so expli
s 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
isting 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.
Carl
--
You received this message because you are subscribe
mentation 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
y
reason Django shouldn't do it by default, since many users won't even
realize how much their response time is being hurt by the lack of it.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and
st_finished signal
(which is the 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 dev
ig 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 gaze of "git annotate" cannot penetrate.
Option (4) is very b
s 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 subscribed to the Google Groups
ll 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 because you are subscribed to
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 developers" group.
To un
t 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
"Django developer
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 star
y'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 (and make things more o
On Feb 20, 2013, at 6:25 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Feb 20, 2013 4:41 PM, "Carl Meyer" <c...@oddbird.net> wrote:
> > On 02/20/2013 04:25 PM, Nick Phillips wrote:
> > >> There was extensive back-and-forth discussion of
ns. 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
sy, 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 this message be
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 unsubscribe from this group
ctionTestCase) 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.
Carl
--
You received this messa
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
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_current_for_request or similar. That
makes s
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 anywhere (in any file
OTE_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 inaccessible.
> Is anyone strongly opposed to this? If not, in Aymeric's spirit of
> decisiveness, I'll push it forward.
I'm fine with new requ
bscribing 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 stop re
ny
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's position on the ticket: this is a
useful feature for som
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 written a tag like that after are plenty of googling.
I agree that
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 conten
1 - 100 of 728 matches
Mail list logo
