On Mar 31, 8:25 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Mon, Mar 31, 2008 at 6:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I'm wondering if something likehttp://django.reddit.com/shouldn't
> > get some sort of official blessing for listing/searching those blog
> > po
On Mar 23, 7:49 pm, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> At the PyCon sprint, I started porting Django to Python 3.0. In the
> process, I had to make a number of changes to Python, so this port
> currently requires the Python 3.0 subversion head (soon to be released
> as 3.0a4).
...
> a) s
Just wanted to note for posterity that the first and fourth items in
the list that started this thread have been taken care of. Thanks
again to David and Brian for diving in.
> * The "simple" backend seems obsolete. The newer "locmem" is
> functionally equivalent for the user, but is suitable for
> I'd like to see a patch that
> aliased "simple" to "locmem" and raised a DeprecationWarning. We'll
> then remove simple in 1.0.
Done: http://code.djangoproject.com/ticket/6086
> > * Should the "file" backend's _file_for_key method be rewritten to use
> > hashes instead of cleaned-up strings? I
A while ago I was picking through the cache system and found a few
things that seemed like they could use cleanup. I'm interested in
hearing thoughts on which of these might be worth pursuing, whether
today or later.
* The "simple" backend seems obsolete. The newer "locmem" is
functionally equiva
Hi all,
For those who don't follow the Django community aggregator I thought
I'd send this out to the lists. I'm arranging an informal get-together
of Django folks next month here in Northampton, MA.
http://open.e-scribe.com/wiki/DjangoDotJune
Here's a condensed version of the info from that p
There's a big spam run happening in the Trac right now. I reopened this
ticket about the problem:
http://code.djangoproject.com/ticket/813
and added a couple links to Trac enhancements that might help.
pb
--
http://e-scribe.com/news/
--~--~-~--~~~---~--~~
You
> 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.
>...
Two small questions: Would the first positional argument to patterns()
just go away? Also, how would t
This is great news. I've been using M-R for a couple months on a
restricted-access production site and am very happy with it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
+1.
--~--~-~--~~~---~--~~
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]
At this point I'm just pretending magic-removal *is* the trunk. I've
ported all my play stuff to it, am using the admin to manage content
for a couple existing non-Django sites, and am developing a production
site in it at work now as well. Most of the time the limiting factor in
functionality is
> Does exist any forum application developed in Django already?
Mike Josephson was working on something called Exhedra, but it's been a
few months since the last signs of life.
http://www.exhedra.org/weblog/
pb
--~--~-~--~~~---~--~~
You received this message
> So I just want to say maybe I'm not testing for this before, but I
> only want to tell you some clues, and hope these clues can help you,
> why not try it yourself and just complain to me?
Sorry -- I should have clarified in the first post that this is about
default behavior in the absence of a
> I'm not test yet. I fount that in the source code.
I recommend testing it before commenting further.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
(Sorry, the example path from my project should have been
project/templates/admin/base_site.html)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
> So you can see, there are several ways to customize admin template,
> fullly according to your template directory. So if you want to custom
> admin template, you can create template directory according to above
> code, and set the root directory in TEMPLATE_DIRS , and the order I
> think it's no
I came across a subtle gotcha with template overriding in magic-removal
today. It stems from these two facts:
1. loaders stop at the first match
2. the admin is now just another app in INSTALLED_APPS
The resulting gotcha: to override admin templates your app must appear
*before* django.contrib.a
Adrian and hugo, thanks for the specifics. Seems like good material for
a wiki page on "alternative" Django setups. If projects are just a
convenience, and some of the biggest Django-powered sites aren't even
using them, that is definitely worth covering explicitly.
I can imagine this might seem
OK, thanks for all the clarifications and corrections. A couple quick
responses:
(Sean)
> For any admin / web type guy a 'site' is a machine / virtual server. It
> contains many projects / apps / whatever.
This actually isn't true for me -- my virtual server has a dozen
domains on it, and for me
What if we changed terminology so that "project" became "site"
throughout the Django code and documentation?
$ django-admin.py startsite myblog
Seems like this would make things a bit easier for the new user, who
has no real idea what "project" means but surely knows what "site"
means.
I was go
Thanks in advance for the status update, Adrian, I think it's a good
idea. I'm not surprised things stalled out a little -- with 0.92 slated
to incorporate magic-removal, there's less incentive to work on the
current trunk, and with so much backwards-incompatible stuff the merge
is sure to be chal
Luke wrote:
> One of the problems with an annotated conf file is what happens at
> upgrade time, when new config options have been added to the system.
> In the case of httpd.conf, it's not too bad for me because dconf
> (Debian conf system) is great and asks me what to do (i.e. doesn't
> overwri
Yeah. Postfix also has the nifty "postconf -n" command which shows you
*only* the settings that differ from the defaults (very helpful when
asking someone else for troubleshooting advice).
--~--~-~--~~~---~--~~
You received this message because you are subscribed
No -- I mean that the generated settings.py file itself would have
descriptions of each setting, including the defaults. See the
bogofilter link.
pb
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
I made a couple dumb settings.py mistakes this morning (e,g, confusing
DEFAULT_FROM_EMAIL with SERVER_EMAIL).
That got me thinking: How about annotating the default settings file to
describe all available settings? I'm talking about something along the
lines of Apache's default httpd.conf.
I als
This is a minor nit, but:
> Using the URLconf defined in foo.urls, Django tried these URL patterns, in
> this order:
>
>1. ^admin/
>2. ^/$
>
> The current URL, /, didn't match any of these.
Now, *we* know that there's an implicit "/" at the beginning of those
rules (as the docs say, "Th
> Except if you remove "__exact" then you can't have fields named
> "select", or "tables", or "fields", or...
True, and changing the framework to use special mangled names for those
special features would have its own downside.
I know there's no easy answer here. Honestly, it's mostly that certa
> > I like it, but I also wish that "__exact" was optional, so I might
> > not be a good person to ask...
>
> Interesting idea, although I'd rather all of the conditional kwargs be
> consistent, personally. Making an exception would make it weird.
Actually, Ian's idea was part of my original thi
Ah, well, it was worth a shot!
pb
Lovely. How about adding accesskeys? E.g.:
GET
POST
Cookies
META
Settings
--
Paul Bissex
http://e-scribe.com/news/
Northampton MA USA 01061-0847
In case this is way off-base or has been discussed to death in IRC,
I'll keep it short. It's just something I've been thinking about as I
build out my first real Django app and follow the (exciting) progress
toward Django's first "real" release. It didn't seem worthy of a ticket
at this stage.
In
31 matches
Mail list logo
