Currently there are at least 4 open tickets [1-4] that propose the addition
of new lookup types. Two of them [1,2] are in DDN because of backward
compatibility concerns.
Following that (IMHO valid) logic makes it impossible to _ever_ add new
lookup types to django without breaking backwards comp
Am 05.05.2010 um 21:45 schrieb George Sakkis:
I'm repeating myself here but if the intention is to really disallow
user-provided ids. it can be done more clearly: raise an exception if
the key does not exist and make the session_key property read-only.
Now it seems like a bug that you can sort
Am 22.04.2010 um 20:28 schrieb Ned Batchelder:
FWIW, I just started using django-compress (http://code.google.com/p/django-compress/
) which works precisely this way. It has pluggable compressors,
control over the versioning of the combined files, and so on.
Also worth noting is django_com
This seems only to be true for python 2.4. In 2.5 and above urlopen
will
happily accept IDNs.
Are you sure?
Yes:
~/ python2.5
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information
Am 27.02.2010 um 21:02 schrieb Fraser Nevett:
Validation of IDN (Internationalized Domain Names) was added in
[12474], but I noticed that the verify_exists option doesn't work when
you use an IDN. This is caused by urllib2 not supporting IDN and the
validation code using the original unicode ve
Hi,
Am 23.01.2010 um 14:01 schrieb Brian Rosner:
from django.db.models.signals import pre_save
from django.dispatch import receiver
@receiver(pre_save, sender=MyModel)
def my_receiver(sender, **kwargs):
...
Just an idea:
Wouldn't it be a bit nicer API to have receiver be a method on Si
> Russell raises my biggest concern with this proposal. There are
> a lot of smart folks in the Django-Developers end of things that
> can cobble together a pretty legit regexp that covers the
> majority of cases with no horrific DOS cases (e.g. last security
> issue).
>
...
> My initial candida
Hi,
in some projects I've had to interface with external authentication
sources that did expect the return-to URL in other formats than "%
(LOGIN_URL)s?%(redirect_field_name)s=%(url)s" (In one specific case it
was, e.g. required that the return URL had to be base64 encoded).
AFAIK there are curr
Hi,
ticket #9764 has been in state DDN for some time now. I think it would
be beneficial to have IDN support built in to django.
Now my question is is: Is the ticket in DDN because of general
conceptional concerns or because of the specific patch? If the patch
is the reason I would be perf
Am 11.08.2009 um 16:50 schrieb Alex Gaynor:
>
> This is still true IMO, but there's another issue here. DDT uses
> jQuery, and AFAIK the official position is still that we aren't
> choosing a JS lib (although clearly Zain's work is rapidly moving us
> to the point where a decision has to be made
Am 04.08.2009 um 18:31 schrieb Daniel Pope:
>
> 2009/8/3 Jacob Kaplan-Moss :
>> 1. Propose a new shortcut function. Bonus points for a patch.
>
> In all my projects I use a file of my own shortcuts:
>
> http://dpaste.com/hold/75120/
>
There is also django-annoying [1] which has (besides some IM
Am 06.07.2009 um 11:20 schrieb Zain Memon:
> Play around and let me know what you think -- especially if you run
> into any bugs :)
Hi,
looks nice. But there are a few things that don't quite "feel right"
yet:
- The Drag handle looks like a checkbox as Adys already said
- The calculation o
Am 18.06.2009 um 14:35 schrieb Luke Plant:
>
> On Thursday 18 June 2009 01:03:15 Waylan Limberg wrote:
>
>> And that's really what this whole discussion is all about -
>> making the developer who chooses the url scheme feel good about it.
>> The fact is, whether the url I'm told over the phone s
>
> I don't know - maybe my needs are unusual. It's definitely not your
> standard blog app ... so if I am too much on the outskirts for this to
> be something that we consider in the development community, I can
> understand that. But it seems to me that having a dynamic (ie, object
> based) wa
Am 16.04.2009 um 21:12 schrieb Steve Howell:
> http://www.djangosnippets.org/snippets/1444/
>
> In writing this code, it occurs to me that other advanced users might
> want more control over URL resolution, and it seems to me that a
> valuable piece of information would be the "name" of the URL, i
On 20 Mrz., 03:48, Malcolm Tredinnick
wrote:
> I was one of the original people in favour of making this change, but
> since it was decided not to go down that path (disappointingly, it
> seems, mostly through apathy at the time), I think we shouldn't change
> it now. the fact that it will eith
Hi,
since #9666 (SSI-tag variable resolving) got accepted by Jacob lately
I would like to restart discussion about the same functionality for
the url template tag (as was already proposed in #7917).
Pro arguments:
- The url tag is one of the few remaining tags that doesn't accept a
variable as i
17 matches
Mail list logo
