Re: CAS in cache framework

2014-01-17 Thread Curtis Maloney
Is it CAS specifically that you want? Or a Locking primitive? Or some other operation? -- Curtis On 18 January 2014 12:45, Russell Keith-Magee wrote: > > I can't see any reason that we *shouldn't* support it - it seems like a > reasonable primitive to support. > >

Re: Renaming apps.has_app

2014-01-05 Thread Curtis Maloney
On 6 January 2014 10:11, Shai Berger wrote: > On Sunday 05 January 2014 23:26:12 Aymeric Augustin wrote: > > If I were to add magic methods on the app registry I’d probably make it a > > dict of app_label => app_config. This is the most common use case. > > > > Then it would

Re: Forbidding double imports

2014-01-04 Thread Curtis Maloney
I submitted a patch some time ago to do a small part of this, on models, but it was rejected... As a long time loather of overlapping import paths, I'm with Florian on this one :) [Oh, and the layout change was 1.4, not 1.3 :) ] -- Curtis On 5 January 2014 09:24, Florian Apolloner

Re: Registering signal handlers

2013-12-22 Thread Curtis Maloney
mport issues. > > It seems providing a reliable initialization signal is one of Aymeric's > main goal. > > Simon > > Le dimanche 22 décembre 2013 03:22:29 UTC-5, Curtis Maloney a écrit : > >> Reading the posts on App reconfigure reminded me I wanted to raise this &g

Registering signal handlers

2013-12-22 Thread Curtis Maloney
Reading the posts on App reconfigure reminded me I wanted to raise this for discussion. Recently we've been suffering circular imports, and the majority are, IMHO, caused by people importing "receivers" in the apss __init__.py. By convention [in our app, at least] "receivers.py" registers all

Re: Problem with number format when not using L10N

2013-12-19 Thread Curtis Maloney
I recall helping someone on #django with something similar to this, where the documentation, logical expectations and actual code went in rather different directions. There was a condition where despite the setting being observed at one layer, a lower layer then went and ignored it anyway... will

Periodic Updates

2013-12-09 Thread Curtis Maloney
as posts on the mailing list, but of course it would also help if I could contact people directly... so if you want to be included, drop me a line :) -- Curtis Maloney -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from

Re: Self-referenced template recursion handling

2013-12-08 Thread Curtis Maloney
unai wrote: >Hello, > >> given this approach, what if the third party app wants to self-extend >> a django admin template for example? > >I'm working on an other solution that instead of relying on loader >skipping >relies on template skipping. > >Imagine you extend to a

Re: Query against MySQL database much slower than Postgres using ORM

2013-11-22 Thread Curtis Maloney
glaring for such a simple query. It usually takes a join or three before the query planner shows its limits. -- Curtis Maloney On 23 November 2013 07:50, Jeff Tchang <jeff.tch...@dishcrawl.com> wrote: > Hi, > Can anyone help with figuring out why basic select queries using the > Dja

Re: ManyToMany relationship can't be saved

2013-11-21 Thread Curtis Maloney
At first glance, I'd guess it's because the PK for ringo and beatles haven't been updated in the instances you have. On 22 November 2013 16:31, Adam Smith wrote: > As I was learning the Django Docs ( >

Re: Add a generic "getter" filter to the built-in library

2013-11-03 Thread Curtis Maloney
Since we're on the topic after some goading from loic I did figure out a backward-compatible way to add call arguments to the filter expression syntax. Essentially, you distinguish between foo|filter:arg and foo|filter(arg...) by looking for : or ( The same parsing could let you have dict

Re: How do features get decided for a release?

2013-10-23 Thread Curtis Maloney
Hi Cody, I suspect many of your questions may be answered in the documentation here: https://docs.djangoproject.com/en/1.5/internals/release-process/ Here's some comments from my experience with using django since its initial release, and recently making a concerted effort to submit code. On

Re: Bacwards incompatibility of #20346 cache middleware should vary on full URL

2013-10-22 Thread Curtis Maloney
If all it meant was that currently cached content would effectively be expired, I wouldn't see this as being anything more than an strong note. But as I'm sure people have created their own tools for building the page cache keys to forcibly expire them [and not yet taken advantage of that

Re: IRC users invited to support PyCon UK Django sprinters

2013-09-23 Thread Curtis Maloney
Congratulations on such a successful sprint! I'm about to run our next HackFest, and know something of how difficult it can be to organise something like this. I can only hope ours is anywhere near as productive and (I assume) satisfying as yours has been! -- Curtis On 24 September 2013

Re: get_cache and multiple caches

2013-09-20 Thread Curtis Maloney
OK. So the goals of this effort are: 1) to avoid resource over commitment [e.g. too many connections] 2) to help relieve the burden of concurrency from the cache backends. Issues to avoid are: a) TLS is "slow" (citation, please?) b) New API better damn well be worth it! Is there anything else?

Re: Default session data serializer doesn't support extended data types

2013-09-20 Thread Curtis Maloney
I talked with the OP [or someone who talks a _lot_ like the OP:)] on IRC about this issue before recommending they open a ticket... and aside from anything else discussed, since someone already saw fit to include an extended JSONEncoder class in core/serializers, why doesn't the session machinery

Re: get_cache and multiple caches

2013-09-20 Thread Curtis Maloney
Yeah... simpler solution is simpler :) -- C On 20 September 2013 17:04, Florian Apolloner <f.apollo...@gmail.com> wrote: > > > On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote: >> >> I guess the remaining question to address is : close()

Re: get_cache and multiple caches

2013-09-20 Thread Curtis Maloney
September 2013 01:33, Florian Apolloner <f.apollo...@gmail.com> wrote: > Hi, > > > On Wednesday, September 18, 2013 1:29:25 PM UTC+2, Curtis Maloney wrote: >> >> 1) Can we share "ad-hoc" caches -- that is, ones created by passing more >> than just the

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

2013-09-19 Thread Curtis Maloney
I feel compelled to comment here... On 20 September 2013 09:32, Richard Ward wrote: > > I don't think that what I was trying to do (continue using a transaction > after an insert failed) was too outlandish. I'm not demanding that Django > should allow me to do it (tho

Re: get_cache and multiple caches

2013-09-18 Thread Curtis Maloney
red caches, and retain get_cache for the old, ad-hoc, non-shared caches. -- Curtis On 7 September 2013 22:32, Florian Apolloner <f.apollo...@gmail.com> wrote: > Hi, > > > On Monday, September 2, 2013 6:39:09 AM UTC+2, Curtis Maloney wrote: >> >> Whilst it's conceivable

Re: Benchmarking 1.5 vs 1.6

2013-09-15 Thread Curtis Maloney
nssi.kaariai...@thl.fi>wrote: > On Sunday, September 15, 2013 3:13:09 AM UTC+3, Curtis Maloney wrote: >> >> Hey, thanks for that! >> >> It would be nice to have something that would chart this over time... >> something like some people have set up for GCC. >&

Re: Idea about authentication

2013-09-15 Thread Curtis Maloney
Actually, you'd just speed up their attack, since most failed attempts would be quicker than others. If you look in the crypto utils, you'll see a "constant time compare" ... this is a common thing in crypto circles to avoid leaking "how close" the guess was by how quickly the mismatch was found.

Re: Benchmarking 1.5 vs 1.6

2013-09-14 Thread Curtis Maloney
Hey, thanks for that! It would be nice to have something that would chart this over time... something like some people have set up for GCC. I've never been able to get djangobench to give meaningful results, otherwise I'd do it. Mmm... perhaps I've just found a use for my odroid :) -- Curtis

Re: Support POST of application/json content type

2013-09-09 Thread Curtis Maloney
On 9 September 2013 19:50, S Berder wrote: > Gents, > to sum it up, arguments made and details of how I see the > implementation of a response/request encode/decode framework: > > * need a pluggable interface so current content-types are supported >

Re: Thinking about NoSQL support

2013-09-05 Thread Curtis Maloney
> > > > I wish people would stop abusing the term "NoSQL". Your target concept > is > > Non-Relational data stores, not SQL itself. There's a whole bunch of > > relational stores that don't use SQL, one of them is even called NoSQL!) > > > > to me, "Non-Relational data stores" still sounds as

Re: Thinking about NoSQL support

2013-09-05 Thread Curtis Maloney
Well, there was the django-nonrel project, for trying to wrap non-relational stores [such as Mongo] in a faux relational layer, so they could then be wrapped in the ORM. Always felt like a tremendous waste of resources to me -- why use a non-relational store just to pretend it _is_ one? My view

Re: Support POST of application/json content type

2013-09-04 Thread Curtis Maloney
To weight in from an author of a different API tool In django-nap there's a simple "get_request_data" method which, essentially, determines how to parse the request according to the content type. However, currently each API only supports a single serialiser format [and HTTP Form encoding] so

Re: Support POST of application/json content type

2013-09-03 Thread Curtis Maloney
Someone remind me never to post to list before I've had my second coffee? :) Of course the above would trivially be handled using middleware. -- C On 4 September 2013 10:05, Curtis Maloney <cur...@acommoncreative.com>wrote: > What do people think of an extensible registration

Re: Support POST of application/json content type

2013-09-03 Thread Curtis Maloney
What do people think of an extensible registration approach to handling request content types? Something along the lines of ('POST', [list of content types], class to handle it) This would mean adding a request.JSON would be simple for the projects that want it, and even overriding how the

Re: get_cache and multiple caches

2013-09-01 Thread Curtis Maloney
> > > On Sunday, September 1, 2013 4:34:54 AM UTC+2, Curtis Maloney wrote: >> >> I've a possible solution - https://github.com/funkybob/** >> django/compare/simple_caches<https://github.com/funkybob/django/compare/simple_caches> >> >> Basically, the existin

Re: Circular dependency in forms+views+models

2013-09-01 Thread Curtis Maloney
Given both the docs for get_absolute_url and reverse demonstrate using string references only, I think adding in clarification of why it's preferred is worthwhile. I still find it surprising how often I need to tell people on #django to not import models just to reference them in relation

Re: get_cache and multiple caches

2013-08-31 Thread Curtis Maloney
I've a possible solution - https://github.com/funkybob/django/compare/simple_caches Basically, the existing API and behaviours are still available through get_cache, but you can avoid duplicate instances of caches using django.core.cache.caches[name] -- Curtis On 31 August 2013 15:44, Curtis

Re: get_cache and multiple caches

2013-08-30 Thread Curtis Maloney
As a simple short-term solution, why not cache calls to get_cache that don't pass additional arguments? That is, ones that only get pre-configured caches. -- Curtis On 25 August 2013 23:26, Florian Apolloner wrote: > Hi, > > so when reviewing

More input on #20945

2013-08-21 Thread Curtis Maloney
Was just after some more eyes and opinions on https://code.djangoproject.com/ticket/20945 Current PR is at: https://github.com/django/django/pull/1490 This patch does two things: 1) it allows specifying on a {% cache %} tag which cache to use {% cache . using="cachename" %} 2) it makes

Re: Usage and documentation of F()

2013-08-19 Thread Curtis Maloney
ther handy "SQL Standard" functions/expressions are there that people would love to use? -- Curtis On 20 August 2013 02:40, Andre Terra <andrete...@gmail.com> wrote: > > On Sat, Aug 17, 2013 at 10:22 PM, Curtis Maloney < > cur...@acommoncreative.com> wrote: > >

Re: Usage and documentation of F()

2013-08-17 Thread Curtis Maloney
If, at the same time, perhaps ExpressionNode got a mention too, that could really open up some opportunities :) On 17 August 2013 21:17, Some Developer wrote: > On 14/08/13 10:05, Marc Tamlyn wrote: > >> (Disclaimer: I didn't write any of this code, I'm just working

Re: django.utils.functional.cached_property

2013-08-07 Thread Curtis Maloney
On 8 August 2013 09:31, Russell Keith-Magee wrote: > On Wed, Aug 7, 2013 at 8:10 PM, Daniele Procida wrote: > >> On Wed, Aug 7, 2013, Aymeric Augustin >> wrote: >> >> >The main drawback of the current implementation

Re: Security Advisory: BREACH and Django

2013-08-07 Thread Curtis Maloney
be retrieved by simply xoring it with the salt. The salt is changed every request. -- Curtis Maloney On 7 August 2013 16:56, simonb <bno...@gmail.com> wrote: > How about requiring that if csrfmiddlewaretoken is set, no matter what > http method (GET, POST...), it is correct otherwise

Re: Streaming sitemaps

2013-07-25 Thread Curtis Maloney
ect.com/ticket/13910 > > On Friday, 26 July 2013 10:20:06 UTC+10, Curtis Maloney wrote: > >> We ended up splitting out sitemaps up... and caching them heavily. >> Pre-generating periodically would be equally effective. >> >> I can, however, see the merit in a

Re: Streaming sitemaps

2013-07-25 Thread Curtis Maloney
layer would also mitigate the problem. -- Curtis Maloney On 25 July 2013 23:51, Benjamin Wohlwend <piquad...@gmail.com> wrote: > Hi Julian, > > after having a site almost taken down by an over-eager spider downloading > the sitemaps dozens of times in parallel, I learned the

Re: Deprecate FCGI support in Django 1.7

2013-07-23 Thread Curtis Maloney
ot;django-fastcgi"? I think it > should most likely be a generic wsgi to fastcgi binding, right? Or is this > project mainly the django management commands? > On Jul 22, 2013 8:07 PM, "Curtis Maloney" <cur...@acommoncreative.com> > wrote: > >> Well, h

Re: Deprecate FCGI support in Django 1.7

2013-07-22 Thread Curtis Maloney
Well, having started looking over the flup source, I can see a lot of useful code to crib, as well as a few critical path bits that can be optimised [without even reducing readability!] So, if you feel like helping out with django-fastcgi ... I'm happy for the help :) -- Curtis On 23 July

Re: Deprecate FCGI support in Django 1.7

2013-07-21 Thread Curtis Maloney
My understanding was Django is a WSGI application, and as such its role is to process requests handed to it. It isn't the server as such. It's the role of a WSGI publisher to accept requests and pass them on to an appropriate handler. So, uWSGI, gunicorn, flup and mod_wsgi as the Publishers we

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Curtis Maloney
On 21 July 2013 02:30, Some Developer <someukdevelo...@gmail.com> wrote: > On 20/07/2013 14:02, Curtis Maloney wrote: > >> I'm more or less building atop flup as it is, however I plan to shed >> anything not related to FastCGI. >> >> For me it's a chance to g

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Curtis Maloney
Juan, technically Django isn't a server at all... whether it's sync, async, multi-threaded, multi-process, or a mix of any of them is up to the wsgi publisher used. Take, for example, gunicorn, which can be any of the above, with options to plug in others when they're thought up. -- Curtis On

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Curtis Maloney
I'm more or less building atop flup as it is, however I plan to shed anything not related to FastCGI. For me it's a chance to get down and dirty with raw protocols again... I do agree there is a shorter path to just applying Django's "fixes" to a fork of flup. -- Curtis On 19 July 2013 22:14,

Re: Deprecate FCGI support in Django 1.7

2013-07-18 Thread Curtis Maloney
ble. And by "help", it could just be as much as feature requests, documentation, or testing [always testing! :)] -- Curtis Maloney On 19 July 2013 08:53, Javier Guerra Giraldez <jav...@guerrag.com> wrote: > On Thu, Jul 18, 2013 at 5:30 PM, Juan Luis Boya <ntr...@gmail.com>

Re: Hybrid Property request

2013-07-17 Thread Curtis Maloney
On 17 July 2013 21:18, Jonathan Slenders wrote: > This is really nice. Both have their use cases, but I'm prefering the > second when possible, because it's much more flexible and preserves > database consistency. > With the same efford you can make the following

Re: Deprecate FCGI support in Django 1.7

2013-07-14 Thread Curtis Maloney
SGI library built that supports Django, we're just closing the door on this avenue... [I say this despite my personal loathing of HostGator... :)] -- Curtis Maloney On 15 July 2013 11:35, gilberto dos santos alves <gsa...@gmail.com> wrote: > i start 2 months ago using fcgi inside an

Re: Proposal: make Model __unicode__() default to self.name

2013-07-10 Thread Curtis Maloney
Luke beat me to it... We have a couple of abstract models which will fall through a small list of field names, trying to guess a useful default for __str__ ... but it makes me feel dirty every time I see it. Beyond "blessing" a particular (set of?) field names as default str names... this also

Re: Adding a OneToMany Relationship to Django

2013-07-10 Thread Curtis Maloney
I've seen enough people in #django suffering because they need a FKey on a table they simply can't alter -- be it because it's in a 3rd party app, or simply a table their DBA won't permit them to alter, or what have you. In the end they wind up having to create the equivalent of a m2m through

<    1   2   3