I've added these docs now, or at least a good first stab at them.
Suggestions for improvements are welcome, patches are more welcome, as
always :-)
I backported to 1.1.X, and tried to remove any anachronisms.
Regards,
Luke
--
"Outside of a dog, a book is a man's best friend... inside of a
Hi,
I'm sorry for asking this here, but the question was raised several
time on the -users mailing list and I don't think we users have a
solution for it.
Basically, the problem is that if I call a templatetag into a block
and it fills me a variiable with the usual context[varname]=something,
Hi Alex --
On Fri, Jan 15, 2010 at 8:41 PM, Alex Rades wrote:
> I'm sorry for asking this here, but the question was raised several
> time on the -users mailing list and I don't think we users have a
> solution for it.
I hate to be a jerk, but django-dev isn't "second-level
Further to my earlier post - I've put the whole branch on Launchpad:
https://code.launchpad.net/~vinay-sajip/django/logging
There's nothing much there at the moment, apart from some code as a
proof of concept. Tested with the following code tacked on at the end
of a vanilla settings.py:
import
Hello everyone!
I just uploaded a simple but mostly complete implementation of model
and queryset polymorphism onto github and bitbucket.
For enabled models, this implementation simply makes all references
to the model's objects polymorphic (be it managers/querysets or
relationship fields).
The
> > In many cases, this is true, but there are other scenarios (certain
> > forms of exception handling, for example) where there is no syntax
> > that's valid in both versions. That's syntax, not just libraries and
> > functions. There's no way to even get a file to parse in both Python 2
> > and
No. You need row based permissions if You will limit User(!) rights. For
example user can edit entries with FK 2. See
http://code.djangoproject.com/wiki/RowLevelPermissions
But AnonymousUser (Guest) don't have any permissions. It's a special and
that the guest can - it's not a permission -
On Jan 15, 1:47 pm, Simon Willison wrote:
> My biggest hangup with the logging implementation was figuring out
> exactly when the logging configuration code should actually run. The
> problem is that Django's startup execution order is poorly defined -
> stuff relating to
On Jan 15, 1:47 pm, Simon Willison wrote:
> On Jan 14, 1:57 am, Russell Keith-Magee
> wrote:
>
> > The other issue that I think still needs to be addressed is the
> > internal usage of logging by Django itself.
>
> My biggest hangup with the
Right. Not constructing the map every time is an obvious enhancement.
My point was simply that using a regex for this particular simple task
doesn't make much sense.
On Fri, Jan 15, 2010 at 9:15 AM, Mike Axiak wrote:
> If you really want to be fast, you can do the following, a la
Or you could use the builtin maketrans/translate pair:
import string
_phone2number_transtab = string.maketrans(string.ascii_letters,
"222333444555666888"*2)
def phone2number(szinput):
return szinput.translate(_phone2number_transtab)
2010/1/15 Mike Axiak :
> If you
I forgot to handle upper case. Note that the following is (~5%)
faster than calling .upper() on the input::
_phone_chars = {
'a': '2',
'b': '2',
'c': '2',
'd': '3',
'e': '3',
'f': '3',
'g': '4',
'h': '4',
'i': '4',
If you really want to be fast, you can do the following, a la urllib.quote::
_phone_chars = {'a': '2', 'b': '2', 'c': '2', 'd': '3', 'e': '3',
'f': '3', 'g': '4', 'h': '4', 'i': '4', 'j': '5', 'k':
'5', 'l': '5',
'm': '6', 'n': '6', 'o': '6', 'p': '7', 'q': '7', 'r':
On Jan 14, 1:57 am, Russell Keith-Magee
wrote:
> The other issue that I think still needs to be addressed is the
> internal usage of logging by Django itself.
My biggest hangup with the logging implementation was figuring out
exactly when the logging configuration code
Isn't the idea of row based permission that you don't need a special
model for that?
-- Gert
Mobile: +32 498725202
Web: http://gert.selentic.net
On Fri, Jan 15, 2010 at 13:55, Anton Bessonov wrote:
> Hello,
>
> It's a false place. All what you need - one Model for
Hello,
It's a false place. All what you need - one Model for Settings.
if SettingsModel.objects.get(code='guest_can_comment'):
can_post
else:
cant_post
You can wrap this in one decorator function.
Harro schrieb:
Because the authentication backend now allows for role based
permissions you
That could also work, another problem is that many times when I am debugging
using tests I will use something like pbd. In this case we will always need
a way to fall back to the single thread mode.
On Jan 15, 2010 2:38 AM, "Russell Keith-Magee"
wrote:
On Fri, Jan 15,
Because the authentication backend now allows for role based
permissions you might have a blog post which anonymous users are
allowed to comment on (create_comment) and another they can't.
Now you would have to have a guest_can_comment flag or something on
the blog post and check that before
Why use regular expressions at all for this? A timeit benchmark shows
a greater than 4x speedup with a rangetest in a loop over the string:
def phone2number(str):
chars = {'a': '2', 'b': '2', 'c': '2', 'd': '3', 'e': '3',
'f': '3', 'g': '4', 'h': '4', 'i': '4', 'j': '5', 'k': '5',
19 matches
Mail list logo