Re: Conventions around plugable backends
On Mon, Dec 7, 2009 at 6:17 AM, Russell Keith-Magee wrote: > So, I'd like to call for a quick BDFL judgement. Everyone else should > feel free to weigh in with opinions if they have opinions, > preferences, or especially compelling arguments either way. My preference is (slightly) for class-based, because it's (slightly) less magic. I think we should try to avoid requiring people to remember what to name things. Put another way, the module-based approach requires the developer to remember one more piece of information -- "Oh, yeah, I have to make sure my class is named Backend" -- and is an opportunity to make a mistake. :-) Unless Jacob feels strongly otherwise, let's go with class-based. Adrian -- 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...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: [Changeset] r2837 - django/trunk/docs
On 5/5/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> > +To retrieve a *single* object rather than a list
> > +(e.g. ``SELECT foo FROM bar LIMIT 1``), slice the ``QuerySet`` to
> > ``[:1]`` and +call ``get()`` on that. For example, this returns the
> > first ``Entry`` in the +database, after ordering entries
> > alphabetically by headline:: +
> > +Entry.objects.order_by('headline')[:1].get()
> > +
>
> Thanks for doing the corrections, but this has confused me -- you can do
> exactly the same by doing this:
>
> Entry.objects.order_by('headline')[0]
>
> The only difference is in caching (the latter will get the item from the
> cache if it the original QuerySet has already been evaluated).
Good call! I've changed the docs. For some reason I was thinking a
simple slice would raise KeyError instead of DoesNotExist, but it does
indeed raise DoesNotExist properly.
These docs, aside from the tutorial, are really coming together. Keep
the corrections and improvements comin'!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Detect SSL/HTTPS
On 5/5/06, Jakub Labath <[EMAIL PROTECTED]> wrote: > Thanks but I don't seem to have the 'wsgi.url_scheme' available in my > request.META could it be becuase I'm using apache and mod_python? Yeah, 'wsgi.url_scheme' is only available via the WSGI handler, not the mod_python handler. I know there's some way to detect HTTPS, but I can't remember it, and I don't have access to an HTTPS Django installation that I can easily check on... There's a sample Django view called "metadata()" in examples/hello/views.py in the new, post-magic-removal trunk. Run that view on your HTTPS server to see all request.META keys. If you find it, let me know, and I'll update the docs. If you're not running the new trunk yet, you should just be able to copy that view off of this page: http://code.djangoproject.com/browser/django/trunk/examples/hello/views.py Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: [Changeset] r2837 - django/trunk/docs
On 5/6/06, Luke Plant <[EMAIL PROTECTED]> wrote: > But, thinking about it, perhaps it should actually raise IndexError in > this situation, and use DoesNotExist for explicit .get() calls? This > would make it act more like other sequences. I don't know how much > code this might impact. That sounds better. I don't think it would impact much code at this point -- go ahead and make the change. > On a related note, I've realised you can use query_set[:] to do a clone, > just like with lists (except it's more like a deep copy, but > inexpensive because QuerySets are immutable). I believe there are some > bits of code external to the QuerySet class that are using ._clone() -- > shall I change them to use the [:] idiom? Let's leave it at _clone(), because it's easier to understand that way. The "[:]" can be easy to miss. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: standalone django templates
On 5/6/06, bickfordb <[EMAIL PROTECTED]> wrote: > i started working on a standalone django templating project: > > http://k9.dv8.org/~bran/djangotemplate-0.2.tar.gz > > is there any interest in merging something this into the main tree? Hi bickfordb, Yes, we're very interested in making the template system downloadable on its own. (Same goes for the ORM and URL mapping bits, as well.) Seems like the main issue is to figure out how to deal with settings/configuration. Right now the "official" Django template system relies on django.conf.settings, and a standalone Django template package would have to provide a way to specify the settings without assuming django.conf.settings exists. (At the same time, this code reorganization should not affect users of the full-stack framework -- django.conf.settings should still exist for them.) There's a ticket for this in the ticket system: http://code.djangoproject.com/ticket/1321 . Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Making URLconfs accept view objects, not just paths to views
I'm thinking more and more that a nice, simple Django improvement
would be to allow URLconfs to specify the view object itself, rather
than a string representing the path to the view.
Old example:
urlpatterns = patterns('',
(r'^map/$', 'mysite.views.the_map'),
)
New example:
from mysite.views import the_map
urlpatterns = patterns('',
(r'^map/$', the_map),
)
This would help make Django apps more portable, because a URLconf
could do a relative import to get the views. Example:
from views import the_map # relative import
urlpatterns = patterns('',
(r'^map/$', the_map),
)
The only downside to this would be the repetition of having to import
the views first before passing them to the URLconf, but I guess you
could do a "from views import *" if you were really lazy. You could
also put the views inside your URLconf, like so:
def my_view(request):
return HttpResponse('Hello world')
urlpatterns = patterns('',
(r'^hello/$', my_view),
)
Note that putting views inside the URLconf is already possible via
something like this (which is a bit ugly but works):
def my_view(request):
return HttpResponse('Hello world')
urlpatterns = patterns('',
(r'^hello/$', __module__ + 'my_view'),
)
Thoughts?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: enhanced inspectdb
On 5/5/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > a month ago, I submitted a patch that makes inspectdb order the models > in a way that is free of forward dependencies (if possible). > > I'm pretty sure it won't break anything since it only involves inspectdb > code. I found it very useful for starting with an existing database. > > Anything wrong with it? Or am I simply too impatient, especially with > the merge? Hey Michael, We've been busy with other stuff -- namely, the merge. I haven't had time to look at the patch, to be honest, but now that the magic-removal merge is done I have more time to look at patches. I'll take a look at it in the next couple of days. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Building the documentation locally
On 5/9/06, tekNico <[EMAIL PROTECTED]> wrote: > BTW, this is my first message here. I am a Python web developer > since 1999, gone through Zope 1, Zope 2, some Zope 3, Quixote, > Twisted, Nevow, and the Divmod stuff. > > One of the reasons I am here is the helpful, if not strenuous ;-P , > evangelization work by C8E. I also wanted to thank you for this > thing of beauty you made. :-) Welcome, Nicola! And thanks very much for your documentation patch; I've committed it. The changes should show up live on the site within 15 minutes. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: CONTENT-LENGTH not being set
On 5/13/06, Martin Ostrovsky <[EMAIL PROTECTED]> wrote: > Is there a reason why CONTENT-LENGTH is always blank in the environ > dictionary that gets passed to WSGIRequest ? > (django/core/handlers/wsgi.py) If you want to set the "content-length" header, use the ConditionalGetMiddleware middleware component. http://www.djangoproject.com/documentation/middleware/#django-middleware-http-conditionalgetmiddleware Django doesn't do this by default for performance. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Exceptions in Templates
On 5/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > The patch in ticket #1852 looks like a good start. I was looking at it > this morning and trying to trace through whether anything else needed > similar modification. Not sure the output it produces is perfect, but it > looks like a good start. FYI, I've checked in that patch. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: RequestContext not working?
On 5/16/06, Andreas Neumeier <[EMAIL PROTECTED]> wrote:
> --- cut ---
> from django.template import Context, RequestContext
> from django.core import template_loader
> from django.http import HttpResponse
>
> def index(request):
> t = template_loader.get_template('portal/index.html')
> c = RequestContext(request)
> return HttpResponse(t.render(c))
> --- cut ---
>
> This is not working at all.
>
> If I replace c = RequestContext(request) with c = Context(), the
> rendered template appears...
Hi Andreas,
RequestContext is working perfectly for me. If you explained what part
of it isn't working for you, somebody could help solve your problem.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: RequestContext not working?
On 5/16/06, Andreas Neumeier <[EMAIL PROTECTED]> wrote: > It looks like RequestContext just dies silently, but I couldn't tell > you for sure. > > I also figured out, there is another installation (rev. 2893 on Ubuntu > Dapper), which looks that it works perfectly. rev 2917 on Breezy seams > to fail for some reason i cannot describe. Where could I have a deeper > look? Does django depend on certain mod_python versions? Does the problem happen on both the Django development server and mod_python? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Standalone template -- updated patch
On 5/15/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > A friend hit the standard problems with trying to use Django's templates > in another application at his work last week. So we sat down on Saturday > and polished Luke Plant's existing patch a little. I have put the new > patch into ticket #1321. > > I would appreciate some review of this, since I believe it is pretty > close to something that is complete. There are documentation updates in > the patch, so I won't go into too much detail: will be a good test of > whether the docs make sense. It is all still heavily based off the > earlier work of Luke and Fredrik Lundh. This is excellent stuff! I've committed it to trunk. Thanks very much to all who contributed to the patch. One tiny question: Why is LazySettings.__setattr__() using this: self.__dict__['_target'] = value ...instead of this? self._target = value Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: psycopg2 beta?
On 5/16/06, Bryan <[EMAIL PROTECTED]> wrote: > I talked with fog, one of the psycopg2 developers, about the current > state of psycopg2. He said that "psycopg 2 itself is stable right now" > and that they just need to complete zpsycopgda 2. From what's been > discussed, it doesn't sound like there is too much that psycopg2 can > change later on that would affect django if it decided to support it > right now. That's good news -- thanks for the update. I just checked in a "postgresql_psycopg2" backend that uses psycopg2 with its psycopg1 compatibility layer. I have not tested this, so it probably doesn't work, but it's a start. One thing, for example, is that the register_type() syntax has changed in psycopg2. Please play around with the new backend and file tickets with patches that make it work! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Standalone template -- updated patch
On 5/16/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> As Luke mentioned in the ticket report (just posting here for the
> archives), it's because in Python
>
> self._target = value
>
> is implemented as
>
> self.__setattr__('_target', value)
>
> for attributes that are not specifically attached to the class at
> construction time. See also: "infinite loop". I started off with the
> same thinking you did, stripped all that stuff out and then spent half
> an hour rediscovering that Luke is pretty smart and had no doubt been
> through the same process.
Aha, that's it. Knew there had to be a reason! I added a comment
around that code in [2929] so it's clear.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: psycopg2 beta?
On 5/16/06, Bryan <[EMAIL PROTECTED]> wrote: > Thanks, Adrian. I took care of the errors you get when you try to > python manage.py syncdb: > > http://code.djangoproject.com/ticket/1904 Thanks very much for the patch -- I've committed it, along with a bunch of other changes. I lightly tested the psycopg2 backend, and it appears to be working smoothly. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Document translations
On 5/18/06, Marcelo R. Minholi <[EMAIL PROTECTED]> wrote: > I'll start the translation for documents '/docs' from svn trunk but > there is some things that I want to know: > > - It's possible to host this translations at the djangoproject website? > - It's possible to get a '/docs/pt-br' area for my translated docs at > the svn? > > I think at this moment that this documents are changed a lot of times > in a short period, so... There is some way to sync these modifications > to make more easy to the document translations mantainer (me on pt-br > ;-)) do their work? Hi Marcelo, Thanks for offering to translate the docs. Yes, we could set up a part of the SVN repository for your translations (and anybody else's, for that matter), and we could display the translated docs on the Django site. This would be excellent. My only concern is that some of the docs have been changing pretty rapidly, as you pointed out. I wouldn't want you to go to a lot of work to translate them, only to have to change the translations a couple of days later. With that said, I think the only docs that will be changing substantially in the near future will be the tutorial docs. Otherwise, they're pretty stable. I'd recommend starting with translation for the non-tutorial docs, such as request_response.txt. Let me know when you've translated a couple, and we can set up the repository. Thanks again for your offer! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: .91 Tarball missing files? (contrib.contenttypes/sessions/sites)
On 5/18/06, m h <[EMAIL PROTECTED]> wrote:
> Perhaps I'm missing something but when I install .91 from eggs, django
> appears to work fine. When I install from the tarball (which gentoo
> does), django complains about missing contrib.contenttypes. Upon
> further investigation contrib is missing contenttypes, sessions and
> sites.
Hey Matt,
Version 0.91 doesn't have contenttypes, sessions and sites in
django.contrib -- only the newest Django development version ("trunk"
in the Subversion repository) has that. I suspect you may have been
reading the development-version docs online, whereas you should read
the 0.91 docs: http://www.djangoproject.com/documentation/0_91/ .
At any rate, I'd encourage you to use the development version instead
of 0.91 at this point.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Additional fields in the many-to-may table?
On 5/25/06, Corey <[EMAIL PROTECTED]> wrote: > Is there a way to add additional fields to the many-to many table, or > is there a better way to accomplish what I want. > > I have a Groups table and an Attributes table with a many-to-many > relationship. > > I want to be able to specify the viewing order of the attribute and if > the attribute is required on a per-group basis. > > I would typically put it in a schema like: > > Group GroupAttributeAttribute > - --- - > id group_id id > Name attribute_id Name >viewing_order >required Hey Corey, Welcome to the Django community. :) The best way to solve your particular problem would be to create a GroupAttribute model rather than using a ManyToManyField in either Group or Attribute. That way, you can give the GroupAttribute model as many extra fields as you want. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Patch review procedure?
On 5/31/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > Just wondering what the procedure is for getting a patch accepted? I > submitted a patch (http://code.djangoproject.com/ticket/1994) a week > ago, and have had no feedback on it so far. > > Is there some kind of monthly IRC meetup where pending patches are > discussed? Or is it just when the core developers have free time for > it? It's the latter. Me, I generally have one afternoon a week in which I focus on clearing out patches and tickets, plus weeknights as my schedule allows. I'm pretty sure Jacob works the same way, although he has been *super* busy traveling and moving lately. Ideas for improving this system would be much appreciated! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Enable Django Quick Start / Database Evolution Support
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > I think you've missinterpreted the writings in the frot-page. OK, everybody, let's settle down... This is slowly turning into a really lame argument that's not much fun to read. More smiles! More comradery! More friendliness! Ilias, thanks for your contributions. We'll examine each one of them on a case-by-case basis, but I cannot guarantee that all or any of them will be committed. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
On 6/1/06, David Elias <[EMAIL PROTECTED]> wrote: > > Well, AS in FROM clause is not support... > > Thoughts, ideas...? Hey David, Sorry for the slow response -- let's take each issue one at a time. What do you have coded so far? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: interesting stuff in django.db.models.base.Model._get_next_or_previous_in_order
On 6/1/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I'm curious how in this function the local variable 'opts' spontaneously > appears on stage. Looks like a bug, but I'm not an expert on meta class > programming. I found this by pychecker, so it might also be dead code. > Else, wouldn't it be self.opts instead? Ah, that should be self._meta instead of self.opts. Thanks for the catch! I've fixed it in [3046]. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Some thoughts on Django and usability
On 6/1/06, James Bennett <[EMAIL PROTECTED]> wrote: > It's a simple truth that you can't please all of the people all of the > time, so at some point in any development process you have to sit down > and mark out three groups: James, you really hit it on the head here. My personal belief is that Django is first and foremost a programmer's tool, and I am more interested in optimizing it for experienced Web developers than for people who have never written a computer program. It would be fantastic if Django *were* easy enough to use that non-programmers could use it, but we shouldn't go out of our way to introduce high-level beginner-friendly features at the expense of confusing and frustrating experienced developers. It's a fine line. You're right to note that we should keep that fundamental focus. I hope this doesn't get interpreted as a slight against non-developers. Ideally developers and non-developers alike would find Django to be a useful tool -- and, actually, that's already happening. But as we develop the framework further, we shouldn't introduce functionality that appeals to the novices at the expense of frustrating the experienced developers. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
get_next_by_FIELD taking parameters (WAS: Re: interesting stuff in django.db.models.base.Model._get_next_or_previous_in_order)
On 6/1/06, gabor <[EMAIL PROTECTED]> wrote: > any chance of this patch getting applied? > http://code.djangoproject.com/ticket/1857 > > it fixes the problem (bug?) that get_next_by_FIELD and > get_previous_by_FIELD don't take params. Hmmm, I'm not sure they should take parameters, as it doesn't fit well with the magic-removal style...What do people think? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
On 6/1/06, David Elias <[EMAIL PROTECTED]> wrote: > I've got the backend's base, create and introspection almost done. > Should i create a ticket or use this one > http://code.djangoproject.com/ticket/1261 and attach the files? Go ahead and use that existing ticket. Looking forward to your patch! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: We're being had
On 6/2/06, Nicola Larosa (tekNico) <[EMAIL PROTECTED]> wrote: > Ilias Lazaridis is a known Internet troll. > > http://www.encyclopediadramatica.com/index.php/Ilias > > Let's stop feeding him/her/it, it's just a waste of time. Nice catch! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Must app names in django be unique?
On 6/5/06, Luke Plant <[EMAIL PROTECTED]> wrote: > Steven Armstrong wrote: > > Just found this [1], so sorry for the noise. I searched through the > > tickets, but forgot to check the mailing list archives. > > Don't worry, it's probably a good reminder, since we never actually did > anything about this as far as I remember. Yeah, let's do something about that... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Logic error in forms/__init__.py?
On 5/26/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> Why on earth does it have:
>
> raise validators.ValidationError, ngettext("Ensure your text is less
> than %s character.",
> "Ensure your text is less than %s characters.", self.maxlength) %
> self.maxlength
>
> Given how the single form would be "1 character", can it ever trigger
> to say: "Ensure your text is less than 1 character."?
>
> At the moment I'd consider this flawed and it is another line in the
> individual .po files that translators need to translate.
Nice catch. What's the proper plural-only way to handle this with gettext?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Site object to contain the protocol? (https..)
On 6/5/06, gabor <[EMAIL PROTECTED]> wrote: > i'm building a https site, and have many times problems with the Site > objects, which kind-of assume that the site is http. > > would it be a good idea for the site objects to also contain the > protocol (http or https)? what do you think? I don't think the Site object itself should contain the protocol, but I suspect we could solve your problem by making some of the Django helper functions more sensitive to http/https differences. There are probably several places within Django in which the "http://"; is hardcoded. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
PROPOSAL: Manager.get_or_create()
Time and time again I have the following Django code:
try:
obj = Person.objects.get(first_name='John', last_name='Lennon')
except Person.DoesNotExist:
obj = Person(first_name='John', last_name='Lennon',
birthday=date(1940, 10, 9))
obj.save()
This pattern gets quite unwieldy as the number of fields in a model goes up.
So I'm proposing a Manager.get_or_create() method, which I believe was
Jacob's idea a few months ago. You would pass it keyword arguments to
use in get(), and you'd pass an optional "defaults" keyword argument
which would specify the kwargs to use in creating a new object if the
object matching the get parameters doesn't already exist.
Thus, the above example would be rewritten as:
obj = Person.objects.get_or_create(first_name='John', last_name='Lennon',
defaults={'birthday': date(1940, 10, 9)})
Note that I didn't specify first_name and last_name in the defaults
parameter. This is a small time- and keystroke-saving optimization:
Any fields not included in the "defaults" dict will be assumed to be
taken from the lookup arguments. That means, in some very basic
examples, you wouldn't even have to specify the defaults at all.
Example:
try:
obj = Country.objects.get(name='Poland')
except Country.DoesNotExist:
obj = Country(name='Poland')
obj.save()
Using get_or_create(), this could be rewritten like so:
obj = Country.objects.get_or_create(name='Poland')
The catch is that the lookup arguments would have to be "exact"
lookups, rather than "__contains" or "__lt", in order for the
arguments to be valid parameters for "defaults".
Here's my implementation, which I'm using in a personal project as a
custom Manager. I'd like this to be rolled in as a default Manager
method.
class GetOrCreateManager(models.Manager):
def get_or_create(self, **kwargs):
assert len(kwargs), 'get_or_create() must be passed at least
one keyword argument'
defaults = kwargs.pop('defaults', {})
try:
return (False, self.get(**kwargs))
except self.model.DoesNotExist:
params = dict([(k, v) for k, v in kwargs.items() if '__' not in k])
params.update(defaults)
obj = self.model(**params)
obj.save()
return (True, obj)
A couple things to note:
* I needed to get both the new object *and* a boolean specifying
whether a new object was created, so get_or_create() returns a tuple
of (new_object_created, object). This is a bit inelegant, but I can't
think of any more elegant ways of returning both of those values.
* Currently this assumes the model has no field named "defaults". This
is a bit of a smell. Better solutions?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
insert_or_replace()
On 6/6/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > any chance of getting a insert_or_replace function as well? > > to do something similar to mysql 5's > > INSERT INTO table (a,b,c) VALUES (1,2,3) > ON DUPLICATE KEY UPDATE c=c+1; > > http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html > > (which is the other common pattern I'm seeing in my code) Maybe I'm not understanding correctly, but aren't you describing what Django already does when you call save() on an object? If the primary-key value is already in the database, it does an UPDATE; otherwise it does an INSERT. Or are you wanting to follow this logic for non-primary-key fields? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: PROPOSAL: Manager.get_or_create()
On 6/6/06, Bill de hÓra <[EMAIL PROTECTED]> wrote: > I understand why you might need this, but at the HTTP level, when the > example for this goes into the docs, can it be wrapped inside a > request.POST? That will stop someone somewhere from using get_or_create > via a GET view. Sure, Bill -- good call. I think get_or_create() is more useful out of Web-request contexts (namely, in scripts that import data and do a lot of object creation), but I'll explicitly point the POST preference in the docs. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Issues on making the firebird backend working
On 6/6/06, David Elias <[EMAIL PROTECTED]> wrote: > Adrian, assuming that you are working on database support, are any > plans that each backend may add sql statements to the sqlall output in > the future? I've got nothing against adding a backend-specific hook for altering the "sqlall" output. We haven't had that need before, but if we need it now, no problem. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Solving the POST-data-lost-after-redirect problem
http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata It's about time to solve this one. Who has a creative, elegant solution? :-) Some ideas, just to start discussion -- * THROW ERROR ON POST: The CommonMiddleware, when adding a slash and redirecting, can check for POST data. If it finds any, it somehow logs the error or otherwise alerts the developer. Maybe if DEBUG=True it can actually display an error, with a custom-built message saying "You need to change so-and-so form action to so-and-so URL"? I can't think of any case in which a POST to a page that needs to be redirected would be intentional, and if we only do it for DEBUG=True I think this may be acceptable. * THROW ERROR ON FORM DISPLAY: If the APPEND_SLASH setting is set to True and the CommonMiddleware is activated, Django could check the output of every page for a whose method is POST and has an "action" whose URL doesn't end in a slash. Then it could somehow alter the page to display an error on it. This solution is horrific, but I'm mentioning it here for diversity. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: errors vs. "advisories"
On 6/7/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > Now, is there interest in having such a thing in Django? Currently, I try to > keep the > patching minimal, but I don't see how I could avoid it. If this would go into > Django > eventually, it could be solved cleaner and easier. For example, currently I > have a > separate AdvisoryFieldMixin, and fields that have advisories use this mixin > as a second > superclass (after django.forms.FormField) Michael, you have stumbled upon an idea that I've coincidentally also wanted to do since before Django was open-sourced! See http://code.djangoproject.com/ticket/23 , in which I call it "ValidationWarning" instead of "advisory," but the concept is the same. A patch would be very welcome... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
On 6/7/06, Luke Plant <[EMAIL PROTECTED]> wrote: > My pleasure. I've updated it for magic-removal (and that version is > uploaded to my bzr repos), but I need to package it up and release it > properly. When I finally get time to do that I'll post a blog about it > or something. Should we add the HTML-validation middleware to Django contrib? Luke, would you be interersted in that? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: validation-aware models... plans/future?
On 6/7/06, gabor <[EMAIL PROTECTED]> wrote: > so now the decisions are already done, and when all the fields will have > the necessare to_python (+validate) methods, then save will be changed > to call validate, and the task is done? > > or still some decisions have to be done first? > > i'm simply asking whether patches should be sent in for the remaining > fields? Right -- those are the next steps. Thanks for the prodding about this. After that, the plan is to remove the automatic manipulators in favor of something that uses the validation. See Joseph K.'s e-mail to django-developers from a couple of weeks/months ago... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multiple database support (#1142) roadblock
On 6/7/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'd argue that the right solution here would be to push the brains > > farther out to the edge. Have management functions call class methods > > on models to execute table creation, initial data loading, etc, rather > > than having them poll the models for information and construct and > > execute the sql themselves. Something like: > > I don't deserve much of a vote, but when I peaked in manage.py, I > thought the same thing. Wha? All that reflection magic isn't in the > model itself? The reason for that is that the reflection magic is only needed in special situations -- namely, table creation -- so there's no need to load it into memory. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multiple database support (#1142) roadblock
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'd argue that the right solution here would be to push the brains > farther out to the edge. Have management functions call class methods > on models to execute table creation, initial data loading, etc, rather > than having them poll the models for information and construct and > execute the sql themselves. As I mentioned in another note to this thread, things are the way they are because I didn't want to load all the rarely-used reflection stuff into memory each time a model is used. That said, if it helps your goal (which would be a great Django addition), let's go ahead and make those model methods. One immediate problem I'd see is that it increases the number of reserved words (assuming these are model-level class methods). Perhaps, like "objects" for Managers, we should put all the reflection stuff within the namespace of a single attribute. Or maybe they become Manager methods, to avoid that problem entirely? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
On 6/7/06, Luke Plant <[EMAIL PROTECTED]> wrote: > I'm not sure how useful it is for Mac and Windows users. The middleware > doesn't actually do any validation -- it's done by 'validate' from > Debian's 'wdg-html-validator'. I personally wrap that in a shell > script which beeps and pops up a KDE notification when a page fails. > None of this is very portable! Oh... I was assuming it was using a local copy of the W3C validator or something. I'm not sure this would work, then. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
On 6/6/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I like this one. I would prefer to see the error is thrown whenever we > are going to add a slash and the method is POST. Checking for POST data > is probably over-specialising. The problem we are trying to solve is > User Agents rewriting a POST as a GET, so if the original submission > intended POST then -- whether or not there is data -- we should try to > avoid the User Agents' bug in all circumstances. I've taken care of this in [3109]. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multiple database support (#1142) roadblock
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'll start working in that direction tomorrow, if that seems like a > good plan. I'm going to be mostly internetless for the next 2 weeks or > so, so it will be a while before I can actually submit a patch that's > fully functional. But I can mail or post up what I have so far tomorrow > morning, if there's any interest. Would it be worthwhile to start a > wiki page at this point? Sounds good -- looking forward to it! Yes, go ahead and start a wiki page if you get a chance. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: does django.contrib.comments package have a profanity filter
On 6/8/06, Rickey Zachary <[EMAIL PROTECTED]> wrote: > I have set up a django project using hte built in comment system, i wan > tto filter out comments that contain profanity. I have a generic view > so i cannot use javascript to filter it out on the client side and was > wondering if django had a built in comment filtering system, to filter > out profanity. Yes, the comments are filtered according to the COMMENTS_ALLOW_PROFANITIES setting. For a good time, see the profanity list in django.core.validators.hasNoProfanities. Note that the comments system is (still) undocumented and may change at any time. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Error fetching the "Recent Code Changes" RSS feed on django website
On 6/14/06, Vladikio <[EMAIL PROTECTED]> wrote: > Just a message to the managers of the django website : > I get an error when I try to access the "Recent Code Changes" RSS > feed (on > the page http://www.djangoproject.com/weblog/) > > the link generating the error is : > http://code.djangoproject.com/timeline?daysback=90&max=50&wiki=on&ticket=on&changeset=on&milestone=on&format=rss > the error is : > Ticket changes event provider (TicketModule) failed: > UnicodeDecodeError: 'utf8' codec can't decode byte 0xe5 in position 11: > unexpected end of data Hi Vladikio, That's a known issue, and it's happening because a ticket, or wiki change, or changeset (we don't know) a couple of weeks ago had a funky character in it. See the bug report at http://code.djangoproject.com/ticket/1983 . If you can isolate that funky character, that would be a huge help in fixing the problem. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Custom Manipulators
On 6/13/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > Custom manipulators are a pain. Could we think about integrating this > cookbook recipie into Django? Or at least start a dialogue about > improving this process. > > http://code.djangoproject.com/wiki/CookBookManipulatorCustomManipulator Yeah, refactoring Manipulators is one of the last things I want to have happen before Django goes 1.0. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: HttpResponseSendFile
On 6/14/06, SmileyChris <[EMAIL PROTECTED]> wrote: > I realise there are better ways to send most files. I ask about this > because I'm looking at implementing that "special case" soon > (authenticating files via logged in user in Django), and I was just > wondering about ways to do it. May I interest you in the "Authenticating against Django's user database from Apache" document? http://www.djangoproject.com/documentation/apache_auth/ Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: validate_full never called?
On 6/16/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > I just noticed today that if I have a CharField primary_key, with > 'blank=False', the system doesn't actually ever validate that the > field isn't empty. The validation stuff isn't finished and isn't intended to be used yet. Move along, nothing to see here. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Django and browser game development
On 6/16/06, gastaco <[EMAIL PROTECTED]> wrote: > Also, does anyone know of any previous browser game attempts with > Python or Django in general? My research yields little to no such > projects. My Dark Secret is a Django-powered game site: http://www.mydarksecret.com/ . Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Regressions tests: a suggestion
On 6/18/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > What I would like to propose is that we create a tests/regression/ > subdirectory for these slightly more mind-numbing but important tests. > Same sub-directory structure, etc, as the the modeltests/ directory, but > not in any way intended to be examples of good model technique. Sounds like a good idea. Go for it! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Development Growing Pains: Patch Acceptance
On 6/18/06, Landon Fuller <[EMAIL PROTECTED]> wrote: > So, my plea: I like Django, and I'd like to put a lot of resources > behind using and improving it. If new committers were pulled from the > ranks of solid contributors, new users of Django (like me!) could be > assured that their contributions won't languish, and we won't run > into nasty bugs that have already been found and fixed by another user. Hey Landon, Thanks for the comments. I'd like to restructure our Trac installation into more useful categories, such as: "Still thinking about it," "Patch is good and should be committed with caveats," "Patch isn't good enough," and stuff like that. I think more granular categories like that would help us get more on top of the tickets/patches. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Regressions tests: a suggestion
On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I have managed to get py.test also run doctests with proper database setup > etc. for > Django for my own testing. py.test walks through all subdirectories to > collect test cases. > Are you interested in this way (i.e., using py.test)? No, I'd rather not introduce a dependency on py.test -- even if it's just for the testing framework. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: default escaping (and branch request)
On 6/20/06, Simon Willison <[EMAIL PROTECTED]> wrote: > I've written up a proposal for how we can implement auto escaping > while hopefully keeping most people happy: > > http://code.djangoproject.com/wiki/AutoEscaping I've gotta say, I don't like the concept of auto-escaping on by default. I'd rather not have the framework automatically munging my data behind my back: it'd be a case of the same type of magic that we removed in the magic-removal branch. In-bulk escaping should be an opt-in thing, not an opt-out thing. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: default escaping (and branch request)
On 6/20/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > You're against automatically quoting your data in the database driver? > Let's rip it out, bad magic that munges your data behind your back. > I figured somebody might bring up this example, but it isn't quite analogous. With a database query, you don't really care what the textual output (SQL) is. With a template, you do. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Custom Manipulators
On 6/14/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > > Yeah, refactoring Manipulators is one of the last things I want to > > have happen before Django goes 1.0. > Mind if I take a shot at it? Sure, proposals are definitely welcome. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: handler404 (and 500?) should use RequestContext
On 6/22/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Currently the default handler404 view uses simple Context. This results > that often people relying on passing their stylesheet URLs with context > processors loose this for 404 pages (I have an app that is written > entirely with generic views except a custom handler404 for the single > purpose of having sites style on this page too. > > Is there a reason to not use RequestContext in handler404? If not I > could make a patch correcting it. We changed the default 404 and 500 views to use RequestContext a couple of days ago, so you may not have seen that change. :) Good point, though, about the 500 view not using RequestContext; I've just reverted it so that it doesn't use RequestContext, to lessen the chance that something could go wrong in displaying that template. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Merging multi-auth to trunk?
On 6/23/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Time for yays or nays to merging the mutli-auth branch into trunk... > I've been running it for a few weeks without any problems, so I'd say > it's pretty much stable. I haven't looked at that branch at all, but if you've been running it smoothly, let's go for it. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Qustion on changeset 3108
On 6/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Does this mean there might be a change of heart on the same sort of
> thing for ifequals (Ticket #1209)?
> http://code.djangoproject.com/ticket/1209
Nah, the {% ifequal %} syntax would be too weird with "and"s and "or"s
embedded in there.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Single-step object creation?
On 6/26/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > >> p = Person.objects.create(...) > >> > >> Which is kinda orthogonal to ``get_or_create``. > > > > +1 - This is more appealing to me. As well as being orthogonal to > > get_or_create, it parallels the behaviour of the m2o/m2m descriptors, > > which have a create call to construct a new object as part of the > > related set. e.g.: > > > > myarticle.authors.create(name="...", ...) > > > > creates a new Author object with a relation between myarticle and the > > new Author. > > Yeah, as I read over my own email I'm inclined to agree with you -- I > think ``objects.create()`` seems a bit nicer. Yeah, Klass.objects.create() seems like the best way to go. Should be simple to implement, as well. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Unicodification of Django
On 6/28/06, Andrey Golovizin <[EMAIL PROTECTED]> wrote: > I am using Django for about half a year and it rocks. Indeed, it would rock > even more if it switched from using UTF-8 bytestrings to use unicode strings > everywhere. Some quick thoughts -- I think we should do this. We are, after all, perfectionists. Not only do we want to show even more love toward the international community, I just like the idea of passing Unicode strings everywhere. It seems so clean. The only big problem I see is that it could confuse the (unfortunately large) mass of programmers who don't understand Unicode yet. That is a big potential pitfall. If we're going to do it, we should do it before 1.0, and we'd need extensive tests. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multiple db branch: tests
On 6/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Is it appropriate to have a test that requires sqlite, or should tests > always use the database engine(s) specified in settings? Tests should always use the database engines in settings. > If they should always use the engines in settings, when needing > multiple databases, is it appropriate to kill the test with an error > specifying how the settings must be set up for the test to run when the > needed databases are not defined? Or should the test create the > databases it needs using the default engine? It should work the way it works currently: It should attempt to create a test database (or databases). If any database of that name already exists, it should display a confirmation message. (Does this answer your question?) > Are there any objections to my adding setup/teardown support for model > tests? (Basically: run module.setup() if defined before running tests; > run module.teardown() if defined after running tests.) Yeah, I'm a bit hesitant to do this -- only because the model tests double as our "model examples" documentation, and for that use it's essential that the examples be clear. > Are there any objections to my extending the test db setup/teardown in > runtests to include creating and destroying test dbs for all dbs > defined in DATABASES? I think I answered this question above, but if I didn't, re-ask it. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Request for history: incoming data processing
On 6/28/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Am I missing something or isn't ``request.raw_post_data`` what you > need? AFAIK, ``request.POST`` and friends are lazy-loading, and you > can just access ``request.raw_post_data`` to get the, um, raw post data. > > (See http://www.djangoproject.com/documentation/request_response/ > #attributes). Yeah, this is what I was gonna say, too: request.raw_post_data should do the trick, no? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
i18n: Removing dependency on django.utils.translation from settings files
I'm working on improvements to this new USE_I18N setting I added
yesterday, and I've run into a bit of a problem --
In my local Django sandbox, I've turned django.utils.translation into
a package that contains __init__.py, trans_real.py and trans_null.py.
The __init__.py contains this:
from django.conf import settings
if settings.USE_I18N:
from trans_real import *
else:
from trans_null import *
trans_real.py is the former django/utils/translation.py, and
trans_null.py contains identity versions of the gettext(), etc.,
functions that don't actually do anything. This is a nice, clean way
of avoiding the overhead of all that gettext() stuff if USE_I18N is
set to False.
The problem with this arrangement is that it causes any import of
django.utils.translation to load django.conf.settings -- and the
settings file in itself imports the translation hooks, because of the
LANGUAGES setting in global_settings.py:
from django.utils.translation import gettext_lazy as _
LANGUAGES = (
('bn', _('Bengali')),
('cs', _('Czech')),
('cy', _('Welsh')),
('da', _('Danish')),
('de', _('German')),
# ...
)
So, in order to make this work, I'm proposing that we *disallow*
translation strings in settings files -- so that the
django.utils.translation file can import from settings and we avoid
circular import references.
This leaves the problem: Where do we put the translation strings for
the available languages? For that, we could put the translation
strings in in django/utils/translation/trans_null.py and change any
instance of LANGUAGES to apply the gettext call at runtime rather than
compile time. Or is there a better way to solve the problem?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: i18n: Removing dependency on django.utils.translation from settings files
On 7/1/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> So you could leave the strings in settings.py, providing you define a
> function called gettext_noop. All this function does is return the
> string passed to it (that is all it does for real, anyway). Then the
> strings are marked with as gettext_noop('Bengali'), etc, and it should
> all Just Work(tm).
I've made the changes you've suggested (in a local sandbox), but
there's one problem left: The bottom of django/conf/__init__.py does
the following:
from django.utils import translation
translation.install()
This registers the _() function in the __builtins__ namespace.
That code can no longer live there, because the new
django.utils.translation depends on the USE_I18N setting. But if it
doesn't live in django/conf/__init__.py, where should it live? What's
a place where we can put it where we can be sure it'll always be run?
I'm a bit stumped...
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: i18n: Removing dependency on django.utils.translation from settings files
On 7/2/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > How would you feel about making a requirement that settings must be > configured prior to attempting to use translations. By this, I mean, > Django must know that it is either using DJANGO_SETTINGS_MODULE or > manual configuration prior to trying to use _(). In that case, you could > put the import into __builtins__ into LazySettings._import_settings() > and LazySettings.configure(), because you will know the value of > USE_I18N at the end of both of those methods. That would indeed solve this, but I agree with you that it's not the best solution. Namely, we shouldn't have to require that a person use settings before using _(). > The other thing I can think of is to install a function initially that > installs the "real" function over the top of itself the first time it is > called (see attached lazy-install.py for a proof of concept). The first > time the lazy _() is called, it can check settings.USE_I18N, which will > always be accessible at that point (the first access to "settings" > configures it if it has not already been done). This, I like. The function can originally be installed in django/conf/__init__.py (where the translation.install() call currently lives), and it can load from the django.utils.translation backend appropriately. It's actually not *too* hackish, either...Well, not as much as the other solution, I guess. Any other thoughts on this from anybody? I'll go ahead and commit this some time Monday, although I'm traveling at the moment and may not get to it until Tuesday. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: i18n: Removing dependency on django.utils.translation from settings files
On 7/2/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This, I like. The function can originally be installed in > django/conf/__init__.py (where the translation.install() call > currently lives), and it can load from the django.utils.translation > backend appropriately. It's actually not *too* hackish, either...Well, > not as much as the other solution, I guess. > > Any other thoughts on this from anybody? I'll go ahead and commit this > some time Monday, although I'm traveling at the moment and may not get > to it until Tuesday. I've committed this in http://code.djangoproject.com/changeset/3271 . Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Feedback on New Middleware
On 7/3/06, Ryan Mack <[EMAIL PROTECTED]> wrote: > I've been working on a bit of middleware that delegates view processing to a > callable class instead of a function, and find myself going back and forth > over an implementation detail. I think you may be overengineering a bit. Django's views can be any callable object -- not just functions -- so you can pass callable classes to them. There's no need to use a custom middleware, and there's no need to use decorators. In your views.py: class MethodDelegator(object): "A generic view class that delegates by request method." def __call__(self, request, *args, **kwargs): if request.method == 'GET': return self.GET(request, *args, **kwargs) if request.method == 'POST': return self.POST(request, *args, **kwargs) # ... class MyMethodDelegator(object): "My particular view class that does particular things for my app." def GET(self, request): return render_to_response(...) my_delegator = MyMethodDelegator() And in your urls.py: (r'^somepage/$', 'views.my_delegator'), Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Feedback on New Middleware
On 7/4/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > I think you may be overengineering a bit. Django's views can be any > callable object -- not just functions -- so you can pass callable > classes to them. There's no need to use a custom middleware, and > there's no need to use decorators. Note there's a bug in the code I posted -- MyMethodDelegator should be subclassing MethodDelegator. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Multi-auth branch
On 7/4/06, Douglas Campos <[EMAIL PROTECTED]> wrote: > It was merged already, should I fix the wiki start page? I've taken care of it. Thanks for the pointer! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Development freeze on django.db.models
To all Django committers -- Please don't change any code within django.db.models over the next few days. Stimulated by ticket #2306, I took a look in there (particularly the file query.py) and was a bit taken aback by how monstrous the code has gotten. I'll be refactoring it over the next couple of days as I get time... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: wontfix
On 7/8/06, bradford <[EMAIL PROTECTED]> wrote: > Not off the top of my head. The reason I made this comment is because > I like going through the timeline and having been noticing a lot of > tickets (which I thought were good features/fixes), but were marked as > wontfix by adrian with no explaination and no dialoging before hand > either. Hey Bradford, Like Malcolm said, usually we put a description of why a ticket is marked as wontfix. If you have any questions about particular tickets, feel free to bring it up on django-developers. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: rss for wiki?
On 7/9/06, favo <[EMAIL PROTECTED]> wrote: > Do we have rss for wiki recent change? Hi Favo, Check out the RSS link at the bottom of http://code.djangoproject.com/timeline . It looks like you can tweak the URL to include/exclude bits such as wiki changes, changesets, etc. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: trac updates/changesets not being sent?
On 7/7/06, Deryck Hodge <[EMAIL PROTECTED]> wrote: > Did this ever get resolved? The thread looks like docs generation was > fixed but I see nothing about the django-updates list. I still > haven't seen anything to that list since early June. Is it no longer > used? I have no idea what happened, but it looks like it's back in business: http://groups.google.com/group/django-updates Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Manipulators going away?
On 7/10/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > I've thought that models will gain validation, but manipulators > will stay and provide an additional level of validation for stuff > that e.g. needs custom manipulators. Did I miss something? Can > someone shed some light onto this? Hey Michael, You're right -- models will gain validation, and there will be a helper function/method that returns a data structure that encapsulates form validation/redisplay (like a Manipulator currently does). That'll be replacing the current "automatic" manipulators, which I've never really liked; they were originally intended for use only by the admin site, not by end users, which explains the problems such as "Why does file upload not work for the automatic manipulators" and "How can I use edit inline with the automatic manipulators." Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: a Caching model.manager
On 7/10/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> class SmallQuerySet(QuerySet):
> cache={}
> def get(self, *args, **kwargs):
> cachekey = "%s:%s:%s" % (self.model, str(args), str(kwargs ) )
> if self.cache.has_key( cachekey ) :
> return self.cache[cachekey]
> x= super(SmallQuerySet, self).get(*args,**kwargs)
> self.cache[ cachekey ] = x
> return x
A coupla suggestions for ya:
* Try using the real Django cache framework rather than a dictionary
-- all it takes is a "from django.core.cache import cache", and the
advantage there is that you can choose from different cache backends.
* Your calculation of the cache key is imperfect, because it relies on
str(kwargs) always returning the same thing. It's generally not a good
idea to rely on the str(), repr() or order of a dictionary, because
its keys/values are to be treated as unordered. Maybe you could use a
"normalized" version of the dictionary -- perhaps sort it before
taking str().
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Test framework for end-user applications
On 7/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > I'm almost ready to submit some patches (I still need to do some code > cleanup and write some documentation), but before I do: > 1) Are there any comments on the approach that I have suggested? > 2) Is this a big enough change that people want to see the patch before I > commit it? It shouldn't actually break anything already in place, just > expose some new functionality that might be useful. Yes, please post the patch before committing -- this is definitely a big thing. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Model verbose name restrictions?
On 7/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Historically, was there a wish/need to put interpretable HTML in the > model verbose names? I am happy to go through and add escaping > everywhere they are used in admin (and other places in contrib/), but if > they are needed for some reason not known to me, that will break > something. The alternative is to document that verbose_name and > verbose_name_plural must be HTML safe, but that doesn't feel right. I think we must have had a need for interpretable in HTML in verbose_names at some point, but I'm cool with changing the admin site to escape the verbose_names rather than strip tags...Maybe Jacob has additional insights, as he's the core maintainer of Ellington (and pre-open-source-Django code) nowadays. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: would is_loggedin be better than is_anonymous?
On 7/14/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > And so are we keeping is_anonymous or deprecating it? I guess it would > still be useful for determining whether on not your object is an > AnonymousUser instance, which seems to be it's original intent. We can > keep it and just change the docs to use is_authenticated. Yeah, I tend to agree with this solution (changing the docs to use is_authenticated or whatever the name of the new method is). Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: USE_I18N = False side effect
On 7/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > As far as I can tell when you add USE_I18N = False in your settings.py > it will result in the admin interface of the site to be stripped of > atleast the datetime javascript helper. Hi avansant, I believe I fixed this a couple of days ago; is this still an issue on the latest trunk code? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > I'm currently looking into a possibility to define per Model which MySQL > Storage Engine it should use for creating the table. This would need a new > option called 'db_table_option' for the Model. > > Not only for MySQL would this be handy, for other backends as well. I think > for PostgreSQL the inheritance feature would need this too. Does this answer your question? http://www.djangoproject.com/documentation/faq/#how-do-i-add-database-specific-options-to-my-create-table-statements-such-as-specifying-myisam-as-the-table-type Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: "allow tags" attribute. stays/vanishes? :)
On 7/17/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > i can do it by setting the allow_tags attribute to true > for the given "something" :) > > but this feature is not documented, so before i use it in an > application, i'd like to ask: > > could this be documented, or is this something that will be removed later? Hi gabor, That feature won't be removed later -- you can count on using it. And I've documented it in changeset [3358]. Thanks for the reminder! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Default arguments for RegexURLResolver
On 7/16/06, Martin <[EMAIL PROTECTED]> wrote:
> I just recently found out that if you use the 'include' feature to
> refer to a external URl config file the default parameter dict is
> silently ingored, e.g.:
>
> urlpatterns = patterns \
> ( ""
> , ( r"^lce/guestbook", include ("lce_at.blog.urls"), dict
> (weblog_slug = "guestbook"))
> ### the admin pages
> , (r"^lce/admin/", include ("django.contrib.admin.urls"))
> )
> In this case, the `dict (weblog_slug = "guestbook")` part will be
> ignored silently.
>
> And now I was wondering if this is a bug or feature?
>
> I have changed the code in my local sandbox to take the default_args
> parameter into account when the view is called.
>
> So, if this is considered a bug I can open a ticket and attach patch.
Hi Martin,
How does your patch work? In your example, would it just add
{'weblog_slug': 'guestbook'} to every infodict in the included
URLconf?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > No.. This is about table options. All of them! Not only storage engine > choice. All of the table options anyone can imagine. And "all of the table options anyone can imagine" are supported by that FAQ answer, as long as they can be applied to a table after it has been created. :) I don't think we should add this hook to Django models, for the reasons James has outlined, and because the raw SQL hook mentioned in that FAQ should be more than adequate. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Default arguments for RegexURLResolver
On 7/17/06, Martin <[EMAIL PROTECTED]> wrote:
> > How does your patch work? In your example, would it just add
> > {'weblog_slug': 'guestbook'} to every infodict in the included
> > URLconf?
> it is a fairly simple change (so maybe I over looked something)
Hi Martin,
That answers my question! Sure, go ahead and post the patch to
Django's ticket system -- it'll be a nice improvement. Thanks for the
patch, and for bringing this up!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Generic View Bug and Issues
On 7/18/06, Tyson Tate <[EMAIL PROTECTED]> wrote: > Is there any way I can get a response on this? I really hate to be > annoying and pedantic, but the following problems are literally show- > stopper problems for my Django projects and they're holding up what > is otherwise a working project. I would really appreciate something - > anything! I haven't had a chance to look at this issue, but I'll point out that there's no way this is a "show-stopper" problem, given that, if generic views don't suit you, you can just write five-or-so lines of view code manually... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Wiki spam
On 7/20/06, adurdin <[EMAIL PROTECTED]> wrote: > There are three spam attachments on > http://code.djangoproject.com/wiki/TracReports -- can someone with > delete permissions get rid of them? Looks like somebody's cleared those out. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Ticket #2333 - request for some love
On 7/20/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > However, I haven't had a great deal of feedback on the last set of patches - > one or two positive comments, but certainly nothing concrete enough to lead > me to commit them. Anybody got any comments? Or, alternatively, can anyone > suggest when they will have time to give the matter some thought? Hey Russ, I don't have time at the moment but hope to have some time while I'm at OSCON next week. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Django sprint / 0.95 release at OSCON
As Jacob write on the Django weblog, he and I are going to be at OSCON next week in Portland, Oregon. Malcolm is also going to be there. Who else is planning to come? I'm wondering if we could get some people together for some Django sprinting -- knocking out some tickets, fixing some bugs, adding some features, etc. Anybody up for it? Also, I did a Django tech talk at Google (Chicago office) yesterday, and some Google people asked when 0.95 was coming out. I mentioned we would probably release something at OSCON. Might as well, eh? Most -- all? -- of the magic-removal stuff has settled down, and it's about time we had an official release. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: humanized dates
On 7/22/06, jws <[EMAIL PROTECTED]> wrote: > The humanize middleware should probably handle pretty-printing dates as > well. It should also reflect I18N, if possible. I don't see a need for this, considering Python's built-in strftime() method is capable of formatting date objects as text. Also, the functionality in django.utils.dateformat introduces some other formatting options, with translation strings marked for i18n. Is there another type of date pretty-printing that I'm overlooking? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: [Django] #2406: [patch] new command for management -- runjobs
On 7/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > this patch doesn't implement 'cron' or anything like that. > it just makes it easier to define jobs which the application needs run on a > regular basis If your goal is to cut crontab entries from five to one, just create a single script that does the five things you need it to do; then point crontab at it. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: A proposal for URL generation
On 7/26/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote: > This is a well know problem. You can read about it in the background > section below. The ticket for this problem have been sitting unresolved > for a long time now. I would really like to get some feedback from the > developers. If you like this, I will submit a patch with the > implemenation. Hi Ahmad, Thanks for bringing this up! Actually I've spoken with Jacob about a nice, clean solution to decoupling get_absolute_url(), and I'm hoping to get that committed to Django's trunk some time this week. Stay tuned. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: why are the date-based views restricted to only displaying past-events?
On 7/26/06, monkeynut <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/ticket/2433 > .. hopefully I didn't miss anything, I've been out in the sun all day. Good stuff, Pete! I've committed that patch. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Consider releasing a .95 beta
On 7/27/06, Joe <[EMAIL PROTECTED]> wrote: > I wonder, then, why .95 has been held off so long. Hey Joe, There's no real reason, other than the fact that the core developers all use (and are happy with) the Subversion/development versions of Django, with which we've been enjoying the great changes to Django over the past few months. We're working on the .95 release as I type this, though. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Strip Whitespace Middleware
On 7/27/06, Doug Van Horn <[EMAIL PROTECTED]> wrote: > I don't know if anyone will find this useful, but I thought I'd throw > it out there. > > I wrote a little Middleware class to strip trailing and leading > whitespace from a response: Hey Doug, Thanks for contributing this! If you could, post it to the collection of user-contributed middleware here: http://code.djangoproject.com/wiki/ContributedMiddleware Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Default escaping -- again!
On 7/27/06, Simon Willison <[EMAIL PROTECTED]> wrote: > Here's an idea I don't think anyone has brought up yet: what if > escaping was on by default for templates ending in .html and off by > default for templates ending in .txt? I'm not keen on coupling the template filename to the template contents. Altering behavior based on the name of a template seems a bit too magical. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Bad link in 0.95 release notes
On 7/29/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > "described in the 'Removing The Magic`_ wiki page" > It appears the intent was to link, but there's no link there. Thanks, man. I've made the fix. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Trac login broken?
On 8/1/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > When I try to log into Trac at the moment, I get a 500 error. Can > somebody with access to the system have a look, please. Fixed. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: r3507 - django/trunk/django/db/models/fields cause many-to-many object error!
On 8/1/06, favo <[EMAIL PROTECTED]> wrote: > After updated to r3507, > meets error when visit m2m field. > AttributeError: 'ManyToManyRel' object has no attribute > 'get_related_field' Fixed in [3508]. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Add support for IP, IP:PORT, or PORT command-line arguments
On 8/1/06, Kevin <[EMAIL PROTECTED]> wrote: > Sure would be nice to save 5 characters every time I start the dev > server If you're that keen on saving 5 characters, go ahead and create a Bash alias for "manage.py runserver hostname:8000". If you do that, heck, you'd save *dozens* of characters! :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Convince us to continue using setuptools
It has bothered me for a while that Django's installation (setup.py) requires a working Internet connection. That's because we're using ez_setup/setuptools (http://peak.telecommunity.com/DevCenter/setuptools), which downloads the setup program automatically if you don't have it installed. The thing is, we don't actually *use* any of the advanced functionality in setuptools. Frankly, the only reason we're using it is because setuptools makes it easier to specify which files we want to include in the distribution (via some globbing syntax that's more advanced than the standard Python distutils). This is because we figured it'd be too much of a pain to create a MANIFEST file and keep it updated. Yes, this is a *horrible* reason to use setuptools rather than distutils. So, convince us to continue using setuptools. What incentive do we have to keep using it? I'm not sure the convenience of easily being able to specify a manifest outweighs the horrid stain of requiring an Internet connection just to install our software. Are there any other ways we can take advantage of it, perhaps? I really want to be convinced to continue using setuptools, but I'm drawing a blank... Insights are appreciated! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
