Re: 1.7 release status (RC2 coming soon)

And for those who want to test, remember to use: pip install git+https://github.com/django/django.git@stable/1.7.x to ensure you're testing against 1.7 and not dev :) -- Curtis On 25 July 2014 09:42, Tim Graham wrote: > 2 weeks later and we still have a fairly

Re: Ability to use method based routing

Sounds like you're heading for a cleaner version of the Publisher pattern in django-nap...? On 18 July 2014 07:34, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > Hello, > > Currently implementing a method dispatcher (e.g. a single URL that > goes to

Re: [GSOC] Weekly update

Can I ask as a favour to future works that you record all the performance tuning approaches you use? Many of these will be obvious to seasoned Python programmers, but some of them won't be, and it would be nice to have a catalogue of "things to look out for" to apply to critical paths in Django.

Re: collectstatic - override default ignore list

OT...just writing down this which came to me on the train this morning as I read this thread Does anyone else foresee the practice of having an "appconfig.py" full of subclasses of AppConfigs becoming common? Seems like a nice parallel to settings, allowing a project to specify per-app config

Re: Regression in ValidationError in 1.7

Am I reading this right as "people used to commonly solve this problem by using an internal API, but now we have a public one... AND the old internal API is now changed"? If so, the solution seems obvious -- document that it's time to move the the official solution :) -- Curtis On 27 June

Re: [GSOC] Weekly update

Is there somewhere I can look at your work in progress code? On 21 June 2014 19:57, Daniel Pyrathon wrote: > Hi All, > > This week I have done the following > > *- Openend PR and merged Options (_meta) unittests* > https://github.com/django/django/pull/2823 > This is a

Re: Building a library of SQL functions into Django

Would it be possible to have some sort of registration pattern, allowing people to import per-backend and per-project libs to override and extend the various available functions? I realise this is nothing more than a sanctioned form of monkey patching, but it would at least provide a common

Re: Integrating polymorphic queries in the framework

Hosted version of the talk: http://www.roadside-developer.com/talks/2013-12-12_MelbDjango_MTI.Performance/#/ [Thanks, Brenton!] -- Curtis On 7 June 2014 11:52, Curtis Maloney <cur...@acommoncreative.com> wrote: > Can I draw your attention to Sebastian Vetter's investigation of the &

Re: Integrating polymorphic queries in the framework

Can I draw your attention to Sebastian Vetter's investigation of the relative scalability of different model polymorphism approaches : https://github.com/elbaschid/talks/tree/master/2013-12-12_MelbDjango_MTI.Performance Basically, the "select_related then resolve" approach [used in

Re: Revisiting multiline tags

to collect and organize thoughts >> in one place, not to be a "we will definitely do this" feature plan. >> > > > Understood, a DEP can be accepted or rejected. > > On Wednesday, April 16, 2014 10:48:22 AM UTC+7, Curtis Maloney wrote: > >> I'm happy to co

Re: Revisiting multiline tags

I'm happy to coalesce this into a DEP... is there a format template I can follow? On 16 April 2014 13:46, Russell Keith-Magee wrote: > On Wed, Apr 16, 2014 at 11:36 AM, Adrian Holovaty > wrote: > > Hey, may I suggest writing this up using our new

Re: Revisiting multiline tags

Would it help if I said please? On 4 April 2014 11:29, Curtis Maloney <cur...@acommoncreative.com> wrote: > Have any of you tested my code which gives you multi-line tags? > > I'd be interested in hearing how it fares "in the real world" > > -- > C >

Re: Revisiting multiline tags

Have any of you tested my code which gives you multi-line tags? I'd be interested in hearing how it fares "in the real world" -- C On 4 April 2014 01:52, dude wrote: > More useful example is not ‘very long with’, just a situation with html > code block, which have in left

Re: Proposal for prepared statements API

On 27 March 2014 19:11, VernonCole wrote: > There was a recent query about prepared statements on the db-sig mailing > list, too. Apparently thought is being given to adding such functionality > to Psycopg. If such functionality is added, it could be useful to support, > I

Re: Proposal for prepared statements API

On 26 March 2014 10:10, Florian Apolloner <f.apollo...@gmail.com> wrote: > On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: >> >> Firstly -- can we assume anyone using this feature is not a complete >> novice, and so will take the caveats m

Re: Proposal for prepared statements API

Firstly, I mostly proposed this API in response to others calls for it. Yes, I'd love to have it, but I'm content to leave it in the "too hard" basket. That said, it doesn't mean I'm not going to try to solve these issue :) So: Firstly -- can we assume anyone using this feature is not a

Proposal for prepared statements API

I've been discussing this idea for some time now, and was reminded of it recently... and akaariai has pushed me to put forward this proposal. Prepared Statements. The benefit of prepared statements, for those who don't know, is it avoids repeating the time the Query Planner in the DBMS takes to

Re: django.utils.functional.cached_property

On 20 March 2014 08:58, Florian Demmer wrote: > > > On Thursday, August 8, 2013 6:59:14 PM UTC+2, Łukasz Rekucki wrote: >> >> Hi, >> >> I have some minor nitpicks: >> >> 1. Unlike the standard @property, the current implementation of >> @cached_property doesn't allow for a

Re: Revisiting multiline tags

I've broken, and how much I've altered template parsing performance :) -- Curtis On 9 March 2014 20:47, Curtis Maloney <cur...@acommoncreative.com> wrote: > To try to help the wider community know to contribute comments, I've > included this thread in the latest Django Update. >

Re: Revisiting multiline tags

To try to help the wider community know to contribute comments, I've included this thread in the latest Django Update. My personal stance is -- I know I can add this to the template code trivially (See my django-contemplation sandpit). However, I'm not certain: a) What performance impact it may

Re: my admin theme

Was just looking at your site... and it looks slick (love admin-tools Menus), but some of the deps worry me. BeautifulSoup? ADMINTOOLS_BOOTSTRAP_SITE_LINK = '/' Why is this special? Why doesn't it use staticfiles like everything else? IMHO the problems with admin go much deeper than the

Re: [GSoC] Switching to Jinja2 proposal

gt; > > On Tuesday, February 25, 2014 8:34:14 AM UTC+1, Curtis Maloney wrote: >> >> Did I miss the link to your benchmark code? >> Does it time just rendering, or parsing also? >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>

Re: [GSoC] Switching to Jinja2 proposal

On February 25, 2014 9:43:49 AM AEDT, Christopher Medrela wrote: >I've made some benchmarks. The results are: > >jinja2 empty for 0.028 s >jinja2 include1.094 s >django empty for 0.435 s >django include2.134 s > >Where "empty for" is an empty loop repeated 50

Re: [GSoC] Switching to Jinja2 proposal

I must admit to being conflicted on this project. I'd love to see the measurements and profiling involved in establishing how much "faster" Jinja2 is, mostly to see where DTL could do with some love... However, I don't believe for most people their templates represent enough of a time cost to

Re: GSoC 2014 idea proposal

I think the most commonly requested feature is how to serilise non-Field properties of models. It's easy, but tedious, to do. Perhaps you could write a mixin to help with this, and improve the documentation? However, I don't see this being a task taking more than a few days... -- Curtis On

Re: [GSoC] Switching to Jinja2 proposal

At this point someone should start asking for real-world examples with measurements. I'm personally of the "let's see if we can improve DTL first, then revisit the question" stance. But in order to show any improvements, we must have timings for the current tool. Can people who've suffered

Re: [GSoC] Switching to Jinja2 proposal

On 11 February 2014 12:31, Luke Sneeringer wrote: > On Feb 10, 2014, at 12:16 PM, Carl Meyer wrote: > > It's a problem that we are unable to do things > that would otherwise be no-brainers (e.g. rendering form widgets using > templates rather than by

Re: [GSoC] Switching to Jinja2 proposal

Can I suggest a 3) to this? After getting involved with the internals of the template engine recently, I came to the suspicion that a lot of the speed issues come from highly defensive coding. Now, this is generally to be expected when safety is more important than speed, but I am moderately

Re: Check Framework Feedback

I disagree. If a hint really ought be provided, but can be omitted in the right circumstances, it should be a required value. This will encourage people to provide a hint, or deliberately omit one. Seems more Explicit and Implicit to me... explicit intention to omit a hint? -- Curtis On 6

Re: [ANNOUNCE] Django 1.7 alpha 1 released

This is a huge release, folks! Lots of big ticket items. Lots of lovely toys for everyone to play with:) And still very backward compatible? I reckon you'll have the beta out before I've even finished playing with everything... Power on, people! Keep up the massive works! -- Curtis On 23

Re: CAS in cache framework

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

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: Registering signal handlers

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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?

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

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

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

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

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

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

> > > > 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

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

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

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

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

> > > 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

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

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

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

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()

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()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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