Re: [GSoC] Switching to Jinja2 proposal

2014-02-08 Thread Curtis Maloney
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 firm of the opinion that some careful analysis
of the template code could help reveal places where the same guard [such as
mark_safe, force_text, etc] is being applied repeatedly but could be
avoided.

So my (3) to this is to analyse the template code paths sufficiently to be
able to identify places where these guards can be omitted safely.

--
Curtis



On 9 February 2014 11:11, Russell Keith-Magee wrote:

>
> On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela <
> chris.medr...@gmail.com> wrote:
>
>> Hello! GSoC 2014 is coming and I'm thinking about issue to work on.
>>
>> The template system is one of the components that are of special interest
>> to me.
>> One of the major issues is that rendering templates is slow. The problem
>> could
>> be solved by compiling template to Python bytecode, but it seems to be
>> really
>> hard to achieve, given that there was an unsuccessful attempt.
>>
>
> This should set off a red flag for you. The GSoC project to byte code
> compile Django's templates was implemented by Armin, the same person who
> wrote Jinja2 - and yet the project didn't fully succeed. It's worth
> investigating *why* this idea failed, because it flags one of the reasons
> why "just adopt Jinja2" may not be a viable options.
>
>
>> Why not switching to Jinja2? I thought that somebody else proposed this
>> idea
>> but I couldn't find any discussion; so, please, point me to the
>> discussion if
>> the idea was discussed, otherwise let's discuss it!
>>
>
> It's been proposed in jest, and it's been accepted in jest as well :-)
> However, I don't think there's been a serious proposal to this effect.
>
>
>> The pros are obvious: 1) fast templates, 2) less code to maintain, 3)
>> lot's of
>> companies use Jinja2 (because of slowness of default template system) and
>> builtin support for Jinja2 would be beneficial for them (thing about
>> integrating Jinja2 with settings like TEMPLATE_DEBUG).
>>
>> Now the cons. First of all, one of the design decision is that Django has
>> no
>> dependencies. We can overwhelm it by "static linking" -- I mean copying
>> Jinja2
>> code into Django. At the first glance, it may look like a horrible idea,
>> but
>> think about it in a different way. If we don't switch to Jinja2, we have
>> to
>> maintain entire template system and fix every bug as well as implement new
>> features. If we switch, Jinja2 developers can do this job for us. We only
>> need
>> to forward tickets to Jinja2 developers and update the static linkage.
>>
>
> We're unlikely to vendor a copy of Jinja2. If we went down this road, we'd
> be much more likely to look at using dependencies defined in setup.py.
>
>
>> The second big problem is that switching is a big change and backward
>> compatibility matters. We will need to support both the deprecated Django
>> template system and the new one. However, it doesn't mean double work --
>> we
>> don't need to implement new features for the deprecated system, only bug
>> fixes
>> will be required. Also note, that a lot of companies uses Jinja2 and
>> switching
>> from third-package Jinja2 to Jinja2-builtin-Django isn't an enormous
>> change at
>> all.
>>
>
> Untrue. It *can* be a *very* big change. One of the biggest problems is
> backwards compatibility for custom template tags. There are a lot of these
> out there in the wild, and the way Django defines custom template tags is
> one of the major reasons that a bytecode approach to Django templates is
> difficult.
>
>
>> I'd like to hear your opinion. Feel free to comment!
>>
>
> Personally, I'm -0 on this proposal as described.
>
> Although Jinja2 and Django template share a common base syntax, Jinja2
> includes a bunch of features that I'm not wild about. Django's templates
> are *deliberately* hobbled to prevent the injection of business logic into
> templates. Jinja2 template allow for function calls, array subscripting,
> and all sorts of other programming language structures. I'm not saying
> these things are inherently bad; I'm saying there's a reason why Django
> hasn't included them, and I'm not wild about the idea of switching to a
> default template language that allows them.
>
> I'd be a more supportive of two different spins on this project idea:
>
>  1) Try to pick up where the 2012 GSoC project left off, and continue the
> work to byte code compile Django's templates. However, this project is
> unlikely to get off the ground without a concrete proposal to get around
> the problems encountered the first time around.
>
>  2) Work on the internals of Django to decouple the template engine, so
> that (a), Django's template language is a standalone in the same way that
> Jinja2 is, 

Re: Check Framework Feedback

2014-02-05 Thread Curtis Maloney
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 February 2014 11:04, Florian Apolloner  wrote:

>
>
> On Thursday, February 6, 2014 12:31:43 AM UTC+1, Carl Meyer wrote:
>>
>> > However, I can see how this might be slightly contrary to expectation
>> > for Python developers generally. I'd be interested in hearing other
>> > opinions on this.
>>
>> I don't think there's a reason to require the argument; if `None` is a
>> valid value for the argument, then clearly it is semantically optional,
>> so give it a default of `None` and make it actually optional.
>>
>
> +1, Either make it completely required (eg don't allow None) or let None
> be the default.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2880d3fe-10a9-4270-830a-0e362fea0e09%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDyLTfyFbZNqrKHr3jA8b4W0Ay8fHf0a%3DCJdFY0kRMbyg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ANNOUNCE] Django 1.7 alpha 1 released

2014-01-22 Thread Curtis Maloney
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 January 2014 15:13, James Bennett  wrote:

> Yup, we're on the way to 1.7!
>
> Check out the blog post (which mentions a couple of important issues to be
> aware of *before* trying out the alpha):
>
>
> https://www.djangoproject.com/weblog/2014/jan/22/django-17-alpha-1-released/
>
> And the in-progress 1.7 release notes for a full rundown of what's going
> to be in the final release:
>
> https://docs.djangoproject.com/en/dev/releases/1.7/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg-b0mNWphessOC8WdM2MZb-NRVvZk1H8gcvqPaAx%2BhupQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSD%3DY48UeW9Hcu1e0RcV-snW%3Dhg%3DsujH6wUomTGQCMhVsA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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.
>
> The only real issue is ensuring it either is, or can be, implemented on
> all backends and supported memcache libraries. If you can produce a patch
> that does this, I'd say it has a good chance of being merged into trunk.
>
> Yours,
> Russ Magee %-)
>
>
> On Sat, Jan 18, 2014 at 2:41 AM, Alexey Moskvin  wrote:
>
>> Hi all,
>> there is a usefull (for me now :)) CAS operation in memcache:
>> http://neopythonic.blogspot.ru/2011/08/compare-and-set-in-memcache.html,
>> but I can't find it in django cache api.
>> Are there any reasons for it not to be implemented there?
>> Thank you!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/be66496f-80ee-498a-9e38-f3a6d2c0cbdc%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84_vqVWQfYJ5tGPS1kGZz_O944yFevd1691h6BWbDJp3_w%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAoTQ_1wkBkiOcBkag%3DQ-s1SVdOPEsABy%3DB8dRXjBC1nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 be inconsistent to support `if "django.contrib.auth" in
> apps`
> > and `apps['admin']` at the same time.
>
> That's a little odd. You noted that names are better keys, which is why
> they
> are used in has_app(). Why would labels be preferable for dictionary
> access?
>
> That being said, keeping the freedom for later does make sense.
>

Is the purpose to test if a particular name is installed, or a particular
module?  The distinction could be important now that the two are not
directly related.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSALk3eU4idrpi%2BP5OqixCwb1VhzBrC97D0FZT5n1xLN%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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

> Kill double imports with fire :þ (and now)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9ffe0b96-1dbe-4a27-a5a2-43aca7b3b31b%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSA45cSOji%2BUFGN8GDSgt%2BsGVefbpnzRS%3D6wmCw9RBjEtg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Registering signal handlers

2013-12-22 Thread Curtis Maloney
Well, if you were looking to do so in 1.6 for the scores of suffering
developers _now_... what would you do?


On 22 December 2013 19:55, charettes <charett...@gmail.com> wrote:

> Since Django 1.7 you can lazily reference model signal sender, it might
> help solving your circular import 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
>> 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 the
>> signal receivers.
>>
>> However, as Aymeric points out, puttng code in __init__ is a prime
>> candidate for triggering circular imports.
>>
>> A lot of times we can avoid the problems by breaking the loops with
>> get_model(), however it generally gets applied elsewhere.  We can't always
>> do this in models.py, because often that would require importing other
>> models, and I avoid that as much as possible.
>>
>> So I tried an autodiscover mechanism, just admin, to make it clean, clear
>> and obvious as to when all the receivers were hooked.
>>
>> But...
>>
>> When to run it?
>>
>> If I put it in urls.py, like admin.autodiscover, can I be sure it will be
>> triggered for, say, my celery tasks? Or management commands?  I could put
>> it at the end of settings.py, but that just feels wrong.
>>
>> I'm happy to trace the whole of Django from go to whoa, and decide on a
>> place to put it, but I'd like to hear from the community in general for
>> ideas.
>>
>> --
>> Curtis
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/643a1e10-f4c8-4a90-a96e-17620e7c9843%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSATSiajDZSU5JmDdDnGy4QFYBq7nwffU23Kz3nX2vF8%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 the
signal receivers.

However, as Aymeric points out, puttng code in __init__ is a prime
candidate for triggering circular imports.

A lot of times we can avoid the problems by breaking the loops with
get_model(), however it generally gets applied elsewhere.  We can't always
do this in models.py, because often that would require importing other
models, and I avoid that as much as possible.

So I tried an autodiscover mechanism, just admin, to make it clean, clear
and obvious as to when all the receivers were hooked.

But...

When to run it?

If I put it in urls.py, like admin.autodiscover, can I be sure it will be
triggered for, say, my celery tasks? Or management commands?  I could put
it at the end of settings.py, but that just feels wrong.

I'm happy to trace the whole of Django from go to whoa, and decide on a
place to put it, but I'd like to hear from the community in general for
ideas.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCUci%3DvZJKjUj6ZbbsFXUb__YGy2phRJtRjUcJJyca2vg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 have to dig it
up again...

--
Curtis


On 20 December 2013 08:19, Shai Berger  wrote:

> Hi,
>
> On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote:
> > Forgive me if at some point was arrogant, it was not my intention to
> impose
> > my judgment or criticize, for me, the best framework that exists. Maybe I
> > was not regarded with good intentions and therefore I believe the answers
> > were focused to dodge my proposal.Most likely I knew not express well,
> beg
> > a thousand pardons.
>
> As the person who closed the ticket, your mail here indicates that I may
> have
> been too harsh, and I apologize for that. I would like to assure you that
> your
> intentions appear good, and your proposal was rejected purely on technical
> reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR
> and
> USE_L10N.
>
> However, having looked again, I now think that you do have a case -- while
> for
> the settings you pointed to, the documentation strongly implies the current
> behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR does
> support your interpretation (and in your first message you mentioned
> having set
> NUMBER_GROUPING=3). For both these settings, the documentation says:
>
> Note that if USE_L10N is set to True, then the locale-dictated
> format has
> higher precedence and will be applied instead.
>
> So -- to me, it looks like the documentation is not entirely consistent,
> and
> should be clarified; and while changing the behavior would be problematic,
> changing it to match (some) documentation should be a possibility.
>
> I'm waiting for other opinions -- in particular, anyone involved with the
> introduction of these settings, who can explain the original intentions --
> to
> decide if we should reopen the ticket[1] as is or change it to a
> documentation
> ticket.
>
> Shai.
>
> [1] https://code.djangoproject.com/ticket/21544
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1516598.QbdADRIKfy%40deblack
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAi1yU1XwxR%2B_TSvgVi8VdYrezqSM5LUdc_QTUaqeU%3D%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Periodic Updates

2013-12-09 Thread Curtis Maloney
So, after discussions with various devs, it was recognised that one of the
issues with the 1.6 release cycle was the lack of communication with the
general community about what was happening...  who was developing what,
what the hold ups were, etc.

So, I've decided to undertake the task of periodic [fortnightly for now]
updates on what's going on with Django development, much like the release
manager Status Updates in GCC.  I will attempt to keep track of who is
working on features, and poll you all in the days leading up to a Update.

I will monitor trac for active tickets, as well 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 this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSD99KNagcaiZc2O8ELw8uVYTdtbHJJPi1gC46D-RBxrhg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 self-reference from within a template. All the
>templates are ignored until the very same template is skipped and it
>then
>continues normally.
>
>This allows for apps to extend other apps and for filesystem templates
>to
>extend other TEMPLATE_DIR roots while order is respected.
>
>Now, the tricky part is to identify a template uniquely. I went for
>hashing
>but, as Apollo13 said on IRC, that's just too expensive. After looking
>for a
>while, it seems that both filesystem and app loaders work with absolute
>paths.
>It seems to me the best way to identify a template uniquely.
>
>The beauty of the solution is that template skipping is totally
>relegated to
>app and filesystem loaders. Of course, some changes in
>django.template.loader
>are needed but they are minor.
>
>I'm currently having some debugging issues and I'm quite busy with
>other things
>but I'll try to provide a complete PR this following week.
>
>If you can think of any problems that this solution would arise don't
>hesitate
>in telling ;)
>
>
>Best wishes,
>
>Unai Zalakain

I tend to warn people off thinking of template names as paths. It's an 
implementation detail that they are treated as such by the two default loaders.

Case in point, my gnocchi-cms app is not the only one I've encountered where 
template names are used to look up a table for the contents.

Requiring each loader to include an unique id with each template (even if it's 
just a full path) seems the easiest solution.

Older 3rd party loaders which don't do this would not be able to participate, 
clearly.

[The other reason I discourage this thinking is it helps people to stop trying 
to us relative paths when referencing templates]


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3615b2cc-95fd-44c3-8115-d7f3b48e29cb%40email.android.com.
For more options, visit https://groups.google.com/groups/opt_out.


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

2013-11-22 Thread Curtis Maloney
First, I would recommend you try this with Django 1.6 - the ORM performance
improvements are dramatic!

Secondly, your own tests show that raw SQL to MySQL takes 10 times as long
as Postgres _through_ the ORM... from which it would be reasonable to
conclude that the problem is not the ORM... but simply that MySQL is slow.
(Or is there a digit missing, and PG is merely 4mS faster? which is still
over 8%)

The best way to test that would be to issue the raw sql direct to the DBMSs
and see how long they take.

I know MySQL is not the fastest tool around, but I wouldn't expect it to be
so 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
> Django ORM against a MySQL database vs a postgres database are 40x as slow?
> More info here: https://dpaste.de/04xz. I am using Django debug toolbar
> to measure as well as a management script to just do simple timings.
>
>
> Using Django Debug Toolbar this query clocks in at 43.02ms:
>
> SELECT `wp_posts`.`ID`, `wp_posts`.`guid`, `wp_posts`.`post_type`, 
> `wp_posts`.`post_status`, `wp_posts`.`post_title`, `wp_posts`.`post_name`, 
> `wp_posts`.`post_author`, `wp_posts`.`post_excerpt`, 
> `wp_posts`.`post_content`, `wp_posts`.`post_content_filtered`, 
> `wp_posts`.`post_date`, `wp_posts`.`post_modified`, 
> `wp_posts`.`comment_status`, `wp_posts`.`comment_count`, 
> `wp_posts`.`ping_status`, `wp_posts`.`to_ping`, `wp_posts`.`pinged`, 
> `wp_posts`.`post_password`, `wp_posts`.`post_parent`, 
> `wp_posts`.`menu_order`, `wp_posts`.`post_mime_type` FROM `wp_posts` WHERE 
> `wp_posts`.`ID` = 9310
>
> Queries against a postgres database are around 1-5ms.
>
> - Both databases are sitting in the same datacenter.
> - Ping times are comparable.
> - I have tried using both MySQL drivers and get similar results.
> - Using Django 1.4.2
>
> -
>
> The ORM statement that generates the above:
>
> post = get_object_or_404(Post, id=blogid)
>
> tstart = datetime.now()
> post_raw = Post.objects.raw('select * from wp_posts where id = %s' % 
> blogid)
> tend = datetime.now()
>
> print (tend - tstart).microseconds
>
> The raw statement is 53 microseconds or .053ms. So the ORM is adding over 
> 40ms worth of time. However what I am trying to figure out is why the ORM is 
> adding this much time to the MySQL query vs postgres.
>
>
> I also have some test code for retrieving a post:
>
>
>
> cursor = connections['wordpress'].cursor()
> blogids = [9310]
>
> tstart = datetime.now()
> for blogid in blogids:
>   cursor.execute("SELECT * FROM wp_posts WHERE id = %s", [blogid])
>   row = cursor.fetchone()
> tend = datetime.now()
>
> print "Time (microseconds) to retrieve a single post via raw sql: %d" % 
> ((tend - tstart).microseconds / len(blogids))
>
>
> tstart = datetime.now()
> for blogid in blogids:
>   post = wordpress.models.Post.objects.get(id = blogid)
>   post.guid
> tend = datetime.now()
> print "Time (microseconds) to retrieve a single post via ORM: %d" % 
> ((tend - tstart).microseconds / len(blogids))
>
>
>
> The results:
>
>
> Time (microseconds) to retrieve a single post via raw sql: 46894
> Time (microseconds) to retrieve a single post via ORM: 91875
> Time (microseconds) to retrieve an object off postgres via ORM: 4228
>
>
> Any help would be appreciated.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6035c9f7-a409-4f6d-bef8-7b25302b8e7c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSD-h0cHv%3D_v%3DrMNNDd3R2cxE15ia4hsj0HLBbCJBDW2KA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 (
> https://docs.djangoproject.com/en/1.6/topics/db/models/#extra-fields-on-many-to-many-relationships),
> I found the following code not working. Is it a bug? At least the result is
> unexpected.
>
> ringo = Person(name="Ringo")
> beatles = Group(name="Beatles")
> m1 = Membership(person=ringo, group=beatles,
> date_joined=date.today(),
> reason='whatever')
> ringo.save(), beatles.save()
> print m1.person.id, m1.group.id  # yes, they have values.
> m1.save()  # IntegrityError: membership.person_id may not be NULL
>
>
> Why can't m1 be save, since both its foreign key fields have been save
> successfully?
>
> Thanks.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1d4d456f-abff-48fe-bf4c-0014c50abe9c%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDH7KqXhJCdEdo7QGGOhD7P3hubKLSYEgpu%3D8VBaXHQEA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 lookups, etc.

I was going to implement something like this in django-contemplation [my
template-engine-as-gedanken project] by mangling the AST.. thus letting me
keep performance as well as having Python syntax.

I'm happy to have a go at implementing simple dict syntax, if there's a
chance it will be accepted.

--
Curtis


On 4 November 2013 11:24, Russell Keith-Magee wrote:

>
> On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi <
> emanuele.berto...@gmail.com> wrote:
>
>> I've opened a ticket (#21370) with a proposal for the *inclusion of a
>> generic "getter" filter* in the built-in library.
>>
>> *Why?*
>>
>> Well, because at the moment Django's template system really lacks of
>> support for retrieving data from existing context variables in all the
>> cases in which the name of the attribute we need is determined at execution
>> time.
>>
>
> It's worth pointing out that this is something the Django core team has
> historically rejected, on the basis that it's a slippery slope from here to
> turning Django's template language into a fully featured programming
> language. So -- fair warning -- the default answer here is going to be
> "No"; it's going to take some convincing to flip that position.
>
> However, I will admit that this is a use case for which I have some
> sympathy. Cross-cutting arrays of data is one of those things that is a lot
> more complex to do in the context than it would be to do using a simple
> lookup in a template.
>
> Formally, I'm probably +0.1 :-)
>
>
>> *Syntax:*
>>
>> {{ object|get:attr_name }}
>>
>> Of course the idea is to add a multi-purpose filter which covers
>> different use cases (model instances, arbitrary objects, dicts, lists,
>> tuples, etc.)
>>
>
> *IF* we are to add this, I'd be inclined to do this as a primitive of the
> template language itself, rather than as a template filter. This is a
> fundamental concept in context lookup, not a data transformation (which is
> what filters generally represent).
>
> The minimal syntactic solution would be to use the colon operator to
> denote arguments in the same way as it does for filters:
>
>  {{ object:attr_name }}
>
> or, by introducing square brackets as parseable symbols in the template
> language:
>
>  {{ object[attr_name] }}
>
> The latter has the benefit of being compatible with Jinja syntax; the
> downside is that Django templates starts to look even more like a
> programming language.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq84_QtcWsop_hPYorOdYUnWxJVVe39E%2Bxu%3DAyUtd3GpP1HQ%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCLh_iuYniyz5CJKU1KabQnkhd_nDUx5DveYinBMJSjcA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 24 October 2013 13:45, Cody Scott  wrote:

> I know that I can look at the 1.7 release notes to see what is to come in
> the next release.
>
> How do django developers decide what features to work on?
>

I don't believe there's a specific roadmap for features.

If someone writes a patch, it has a great chance to make it in.  It's as
simple as that (or, can be).


> Is there a minimum time between releases?
>

>From the link above:

"Minor release (1.1, 1.2, etc.) will happen roughly every nine months"


>
> Is there a minimum quota for fixed bugs for a release?
>

Critical bugs [such as data loss or crashes] and security fixes will
warrant rapid release of a Micro version.
Between Minor versions, they can vary a lot.


> Is there ever a poll to see which features the community wants?
>

See the section "Phase one: feature proposal"

Typically, a feature/ticket with code has a great chance to make it it.
 That said, a number of my changes that have made it into 1.7 were proposed
and accepted in a matter of a few days.


> Is there another way that developers get what the community wants?
>

Open a ticket, provoke discussion on the django-dev mailing list, and
champion the ticket -- either by writing the code yourself, or finding
someone to do it for you.

As the release cycle notes say "working code trumps grand design"

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSB4fj_LbqfG%3D2WcBCOV4sd_78a9RwX-fNTHt1TMQ4ddUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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
function being separated to a util module] I'm guessing it'd warrant a
warning to catch up.

Just my 2c.

--
Curtis


On 23 October 2013 05:34, j l  wrote:

> Ticket #20346 is the request that cache keys should be generated from a
> request's full URL rather than path, and the proposed implementation of
> this is backwards-incompatible.
>
> Because the existing keys are a hash of the path, and so, so far as I
> know, we do not have the original path needed to migrate keys, I do not see
> how we can migrate existing keys.
>
> I am alerting everyone to this and wondering if anyone has ideas which
> preserve backwards compatibility.
>
> If a backwards-incompatible change is necessary, I wonder if it would be
> appropriate to change cache keys to be more compatible with looking up
> directly via reverse proxies and webservers. Django cache keys are
> Django-specific module names and hashes, but it might be desireable to have
> them be in a simple, readable format such as
> http://www.example.com/path/to;method=GET;locate=en-us;Vary=Pony;etc.
> Other programs can easily generate those keys in order to fulfill cache
> hits.
>
> Thanks.
>
> Ticket at https://code.djangoproject.com/ticket/20346.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKkhZKz9Q58b%3DdS%3DEw7w6ivqk-Q_Eb_Qeh8N_R9o%2BDZMX%2B1v-A%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDXwiCSUJi%2BpFpNKHbCdn_NAz3as4-kyzchMp_-f6EcSg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


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 08:39, Daniele Procida  wrote:

> On Mon, Sep 23, 2013, Daniele Procida  wrote:
>
> >At the Don't be afraid to commit workshop at PyCon UK today there were a
> >lot of attendees  >latest/attendance_record.html#pycon-uk-in-coventry-22nd-september-2013>
> >(31 of them).
> >
> >Many of them said they'd come to the Django sprint tomorrow (Monday 23rd
> >September), which runs 1000-1230 and 1330-1600 UTC+1.
> >
> >If anyone can be in #django-sprint to help out that would be very nice
> indeed.
>
> I just want to say thanks to everyone who helped the sprinters (or even
> just popped in to say hello) on IRC, but especially Tim Graham, who was
> there throughout the day and really helped make it a success.
>
> It was an excellent sprint. We had 14 people involved, and I think all of
> them were were first-time Django contributors. Several were people who had
> very little experience of this at all (many installed Git and set up GitHub
> accounts for the first time yesterday in the workshop), but today several
> pull requests were made and merged:
>
> <
> https://github.com/django/django/commit/c81b6f7b834da8d8fbcf679679ce158173df3a05
> >
> <
> https://github.com/django/django/commit/98e0453f00958af63b50e70990903eb6a04e1933
> >
> <
> https://github.com/django/django/commit/6a30075eaa52b3d91665195a34901ac450df5bbb
> >
> <
> https://github.com/django/django/commit/a53caf28bf2ab29cf4e78a968b3887ddb6d6e83d
> >
> <
> https://github.com/django/django/commit/41167645b1039067127fa215d4d28296bfa4cfdc
> >
> <
> https://github.com/django/django/commit/e15f7f31d048ead5453b5ee810235cf88b42b3cc
> >
>
> there's one open pull request:
>
> 
>
> and I think a couple more people at least are still working on theirs.
>
> Having friendly strangers on hand in the IRC channels made their first
> impressions of the Django community a very good one. There was a very
> positive (and excited, once people started getting close to making pull
> requests) vibe at our table, and some of the sprinters were beaming with
> delight after their pull requests were merged.
>
> I was taken aback when I saw how many people had turned up for the
> workshop on Sunday (<
> http://dont-be-afraid-to-commit.readthedocs.org/en/latest/attendance_record.html#pycon-uk-in-coventry-22nd-september-2013>
> - over 30 of them), but in fact I think it was the most successful one so
> far.
>
> Daniele
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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?

--
Curtis


On 21 September 2013 01:29, Tom Evans  wrote:

> On Fri, Sep 20, 2013 at 4:13 PM, Florian Apolloner
>  wrote:
> >> It seems more sensible to hook something that has the lifetime of the
> >> request to the request, rather than stick it in TLS, keyed to the
> >> thread serving the request.
> >
> >
> > Jupp, sadly I don't see a sensible way around thread local storage here
> :(
> >
>
> All good points, I just have this mental "HMM" when I see TLS as the
> solution for anything. TLS is already used for things like the
> language code of the current request, which avoids you having to pass
> around a state object or passing down lang_code all down the stack,
> but means that things like URL reversing and resolving benchmarks are
> slow (O(n²)) with USE_I18N on.
>
> The problem with tying everything to the request is that you end up
> with code that only works with requests or request-like-objects. The
> problem with not tying everything to the request is that things get
> slower. :(
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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-use it?

All it does is add support for date, time, datetime and Decimal.

And the answer is: there's no way for a matching Decoder to know when to
decode any of these types, since there's no schema available.

The only "simple" alternative that comes to mind is something like MsgPack,
with a bunch of pre-defined Extension types.

As far as the security benefits, I think Donald has nailed it -- no part of
the system should base its security around relying on the integrity of any
other part.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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()
>>
> Leave it as is I think.
>
>
>> Thinking as I type... it wouldn't hurt, also, to allow a cache backend to
>> provide an interface to a connection pool, so the manager can play friendly
>> with it.  If it doesn't have one, fall back to an instance-per-thread...
>> this would require still hooking request complete, but not so much for
>> "close" as "release".
>>
>
> If it can be added afterwards without to much issues, I prefer to leave
> APIs for connection pools out for now; since it will make the patch
> smaller, which makes it easier to merge.
>
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


Re: get_cache and multiple caches

2013-09-20 Thread Curtis Maloney
I guess the remaining question to address is :  close()

It looks like it was added to appease an issue with memcached, which may or
may not still be an issue [comments in tickets suggest it was a design
decision by the memcached authors].

Thinking as I type... it wouldn't hurt, also, to allow a cache backend to
provide an interface to a connection pool, so the manager can play friendly
with it.  If it doesn't have one, fall back to an instance-per-thread...
this would require still hooking request complete, but not so much for
"close" as "release".

--
Curtis



On 19 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 CACHES alias.
>>
> Imo no, you probably have a good reason if you create ad-hoc ones
>
>> 2) What to do about django.core.cache.cache ?
>>
> Has to stay for now, same as django.db.connection
>
>
>> A separate approach is to introduce a new API to provide access to the
>> shared, pre-configured caches, and retain get_cache for the old, ad-hoc,
>> non-shared caches.
>>
> I think it would be sensible if that API would mimic django.db.connections
>
> Florian.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 that would be nice), but I can see other
> people trying to do it - especially if they are mostly used to MySQL, which
> allows it. It may not be correct, but it is (IMO) intuitive - why should a
> transaction have to be considered completely ruined just because an insert
> failed, when I expected that it may happen? (I don't need an answer to
> that, just explaining my/others thought process).
>

So you don't think that "one step of an atomic operation failing" is reason
to fail the atomic operation?  Doesn't sound intuitive to me.

Django is trying to enforce the _logical_ behavior.  The concept of an
"atomic" operation, even outside the context of DBMSs, is pretty much the
consistent throughout CS.

If you are expecting the step could fail, then you should wrap it in a
sub-transaction - the very reason they exist.  Again, you have an atomic
operation [the insert] that may fail, so you want to gracefully handle it.


> If Django must enforce PostgreSQL style behavior, then an exception at
> some point telling me off for my bad behavior would be useful. IIUC
> correctly I'd get that exception with Django+PostgreSQL but I don't get any
> with Django+MySQL.
>

I absolutely agree that Django should behave consistently in this, despite
the quirks of the DBMS chosen.

Either way I think the docs could be improved: "Wrapping atomic in a
> try/except block allows for natural handling of integrity errors" is not
> the same as "DatabaseErrors must be caught outside the atomic block". Also
> "If the block of code is successfully completed, the changes are committed
> to the database. If there is an exception, the changes are rolled back"
> implies to me that the transaction will be rolled back iff an exception
> causes the stack to unwind past transaction.atomic, but the intent is "If
> there is any DatabaseError [or any other exception raised inside a
> transaction.atomic(savepoint=False)], even if it is caught by user code,
> the changes are rolled back."
>

Always a fan of improving the clarity of the docs :)

[and I blame your expectations of transactions on MySQL... who seem to
delight in ignoring the sane behavior :)]

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


Re: get_cache and multiple caches

2013-09-18 Thread Curtis Maloney
I started working on a CacheManager for dealing with thread local cache
instances, as was suggested on IRC by more than one person.

Firstly, I propose we remove the schema://backend...  syntax for defining
cache configs, as it's no longer even documented [that I could find quickly]

Secondly, have get_cache ask the Cache manager, instead of doing all the
lifting itself.

At this point, I could see two non-trivial things to solve:
1) Can we share "ad-hoc" caches -- that is, ones created by passing more
than just the CACHES alias.
2) What to do about django.core.cache.cache ?

As I was explaining this, something occurred to me: a wrapper object that
remembers the backend/location/params used to create the cache instance,
and deals with accessing the right thread-local instance.

A separate approach is to introduce a new API to provide access to the
shared, pre-configured 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  some cache backend will have the smarts to
>> multiplex requests on a single connection, I suspect that's more the
>> exception than the case.
>>
>
> Agreed
>
>
>> Obviously, the default would be one per thread.
>>
>
> This is what the pylibmc backend does already and memcached should do too;
> the db backend is per thread too since it uses Django's db connection. We
> might wanna supply a building block so that not everone has to implement
> their own variant of the threadlocal stuff :)  [Locmem and filebased
> shouldn't cause any issues either way and can stay as they are I think]
>
> Of course, that could be simplified by just always creating a new instance
>> when more than just a name is provided. [or a "force new" keyword is
>> passed].
>>
>
> I wonder how common it is to supply more than just the name to get_cache
> (aside from tests maybe), I am +0 for making get_cache return "cached"
> instances for a single name and construct new ones for the other cases (+ a
> force keyword if someone really wants the old behavior).
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Benchmarking 1.5 vs 1.6

2013-09-15 Thread Curtis Maloney
So what's going on here:

Running 'query_none' benchmark ...
Min: 0.44 -> 0.000262: 5.9674x slower
Avg: 0.47 -> 0.000290: 6.1906x slower
Significant (t=-12.805744)
Stddev: 0.1 -> 0.00013: 14.5148x larger (N = 50)

--
Curtis



On 15 September 2013 16:31, Anssi Kääriäinen <anssi.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.
>>
>> 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 :)
>>
>
> I have a simple setup for generating graphs over time. Results are
> something like this: http://users.tkk.fi/~akaariai/djbench/model_save/.
> Unfortunately I haven't found the time to automate benchmarking.
>
> When using djangobench it is extremely important to turn all sorts of cpu
> speed throttling off. Power saving features will cause random results. It
> seems the older your hardware is, the better results you will get. Even
> then, if you forget to disable cpu throttling you will get results like
> this: http://users.tkk.fi/~akaariai/djbench/model_creation/
>
> I managed to spot why form_create is 15x slower in average - it is all
> about translation startup speed. A string that wasn't translatable before
> now is, and I guess the first time that string is translated will cause a
> huge spike in runtime. Luckily the rest of iterations are about same as
> always. In short, form_create was a false alarm. Or, see
> http://users.tkk.fi/~akaariai/djbench/form_create/
>
>  - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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.

This is a class of "side channel attach"... worth reading up on if you want
to get further into crypto: http://en.wikipedia.org/wiki/Side_channel_attack

--
Curtis



On 15 September 2013 19:00, Ram Rachum  wrote:

> Hi guys,
>
> I just saw the new release announcement and I had an idea.
>
> What if, in addition to sorting the hard to compute hash for every
> password, we will also store the sha 1 hash of the first 5 characters ofthe
> password's sha1 hash? Wouldn't this allow us to quickly rule out 99% of
> passwords, thereby defending against dos attacks, while atthe same time not
> letting an attacker who obtained the hashes to get the passwords?
>
> I'm not a security expert, just brainstorming.
>
> Thanks,
> Ram.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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


On 15 September 2013 04:21, Anssi Kääriäinen wrote:

> I just ran djangobench comparing 1.5 to 1.6. The biggest thing seems to be
> form_create bechmark, the average is 15x slower. But for some reason the
> minimum runtime is just 1.16x slower. This seems a bit strange. This might
> be worth more investigation.
>
> Otherwise there doens't seem to be anything alarming going on. Most ORM
> operations are slightly faster (likely due to __deepcopy__ removal).
>
> There are a couple of individual benchmarks worth mentioning...
> url_reverse and query_iterator are slower (1.15x and 1.12x respectively).
> The default_middleware and qs_filter_chaining benchmarks have gained a lot
> (2.0x and 3.1x respectively). model_save_existing/model_save_new are faster
> (2x+), but model_creation is slightly slower. I suspect there is something
> going on with connection creation or transactions for model_creation, after
> all model_creation is a convenience method for model.__init__ +
> model_save_new which both aren't slower.
>
> What else? url_reverse and template compliation under i18n slightly
> slower. For the rest of benchmarks, see below.
>
> Running 'default_middleware' benchmark ...
> Min: 0.001260 -> 0.000554: 2.2755x faster
> Avg: 0.001389 -> 0.000681: 2.0394x faster
> Significant (t=8.222155)
> Stddev: 0.00037 -> 0.00048: 1.2843x larger (N = 50)
>
> Running 'form_clean' benchmark ...
> Min: 0.42 -> 0.42: no change
> Avg: 0.49 -> 0.43: 1.1341x faster
> Not significant
> Stddev: 0.4 -> 0.1: 6.6718x smaller (N = 50)
>
> Running 'form_create' benchmark ...
> Min: 0.85 -> 0.99: 1.1657x slower
> Avg: 0.88 -> 0.001396: 15.8410x slower
> Not significant
> Stddev: 0.1 -> 0.00916: 783.3314x larger (N = 50)
>
> Running 'l10n_render' benchmark ...
> Min: 0.011702 -> 0.014151: 1.2093x slower
> Avg: 0.012200 -> 0.014846: 1.2169x slower
> Significant (t=-4.824893)
> Stddev: 0.00233 -> 0.00310: 1.3311x larger (N = 50)
>
> Running 'model_creation' benchmark ...
> Min: 0.000311 -> 0.000400: 1.2860x slower
> Avg: 0.000336 -> 0.000432: 1.2840x slower
> Significant (t=-2.799691)
> Stddev: 0.00015 -> 0.00019: 1.2751x larger (N = 50)
>
> Running 'model_delete' benchmark ...
> Min: 0.000407 -> 0.000468: 1.1500x slower
> Avg: 0.000423 -> 0.000484: 1.1440x slower
> Significant (t=-7.131460)
> Stddev: 0.5 -> 0.4: 1.1807x smaller (N = 50)
>
> Running 'model_save_existing' benchmark ...
> Min: 0.062923 -> 0.021829: 2.8826x faster
> Avg: 0.063206 -> 0.022001: 2.8729x faster
> Significant (t=793.026302)
> Stddev: 0.00034 -> 0.00014: 2.3570x smaller (N = 50)
>
> Running 'model_save_new' benchmark ...
> Min: 0.041341 -> 0.021819: 1.8947x faster
> Avg: 0.063127 -> 0.022379: 2.8208x faster
> Significant (t=76.086085)
> Stddev: 0.00344 -> 0.00158: 2.1770x smaller (N = 50)
>
> Running 'multi_value_dict' benchmark ...
> Min: 0.83 -> 0.85: 1.0230x slower
> Avg: 0.000165 -> 0.000168: 1.0164x slower
> Not significant
> Stddev: 0.5 -> 0.5: 1.0339x larger (N = 50)
>
> Running 'qs_filter_chaining' benchmark ...
> Min: 0.004264 -> 0.001362: 3.1311x faster
> Avg: 0.004311 -> 0.001391: 3.0996x faster
> Significant (t=170.435257)
> Stddev: 0.00010 -> 0.7: 1.2953x smaller (N = 50)
>
> Running 'query_aggregate' benchmark ...
> Min: 0.000467 -> 0.000412: 1.1331x faster
> Avg: 0.000479 -> 0.000423: 1.1322x faster
> Significant (t=11.625112)
> Stddev: 0.2 -> 0.2: 1.0048x smaller (N = 50)
>
> Running 'query_all' benchmark ...
> Min: 0.047256 -> 0.043987: 1.0743x faster
> Avg: 0.049713 -> 0.046489: 1.0693x faster
> Significant (t=3.604195)
> Stddev: 0.00423 -> 0.00470: 1.1104x larger (N = 50)
>
> Running 'query_all_multifield' benchmark ...
> Min: 0.103770 -> 0.099138: 1.0467x faster
> Avg: 0.107616 -> 0.103382: 1.0409x faster
> Significant (t=4.033836)
> Stddev: 0.00495 -> 0.00553: 1.1182x larger (N = 50)
>
> Running 'query_annotate' benchmark ...
> Min: 0.000987 -> 0.000865: 1.1408x faster
> Avg: 0.001006 -> 0.000881: 1.1417x faster
> Significant (t=17.891371)
> Stddev: 0.4 -> 0.3: 1.2235x smaller (N = 50)
>
> Running 'query_complex_filter' benchmark ...
> Min: 0.000308 -> 0.000218: 1.4136x faster
> Avg: 0.000317 -> 0.000223: 1.4175x faster
> Significant (t=27.463980)
> Stddev: 0.2 -> 0.1: 1.3219x smaller (N = 50)
>
> Running 'query_count' benchmark ...
> Min: 0.000392 -> 0.000339: 1.1561x faster
> Avg: 0.000401 -> 0.000347: 1.1571x faster
> Significant (t=13.345028)
> Stddev: 0.2 -> 0.2: 1.0469x smaller (N = 50)
>
> Running 'query_dates' benchmark ...
> Min: 0.001032 -> 0.000884: 1.1678x faster
> Avg: 0.001055 -> 0.000900: 1.1730x faster
> 

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
> (`application/x-www-form-urlencoded`, `multipart/form-data`), new
> types (`application/json`), custom and future types
> (`application/vnd.foobar+json` anybody? See
> http://developer.github.com/v3/media/#api-v3-media-type-and-the-future
> for example, `application/msgpack`, `application/protobuf`,
> `application/capnproto`, etc).
> * decoder/encoder map (content-type, decoder) should be smart to
> handle patterns like `text/*` or `application/*xml*` and match things
> like `Accept: application/json, text/plain, * / *`
> * choice of decoder would be made on the Content-Type header, maybe
> supporting a raw by default so data is just passed in case of unknown
> content type.
> * decoder/encoder should be available through `request` and `response`
> objects.
> * decoded data structure (python object) would be stored in `request.data`
> * first step is to support requests, next step is to handle responses
> with the same pluggable functionality and coherent API.
> * A sensible default for response Content-type would be `text/html;
> charset=UTF-8`. It should be made available through a setting entry
> anyway
>
>
You should also have access to the decision made by the data parser as to
which parser was used, instead of having to infer it yourself from the
content type header.



> Some questions though:
>
> * why keep data and files separated, I see no good reason for this
> except mimicking PHP's structure. An uploaded file comes from a named
> input, I hope to find it in request.data (why do a common structure
> otherwise). I might be missing something but nothing indicates a real
> need for this in django/http/request.py
>

True, there's some added complexity [small as it is] in forms because File
fields need to look elsewhere for their values.


> * isn't more or less any data sent to your backend representable as a
> dict or object with dict access modes? I try to think about
> occurrences where some data would not have a 'name'.
>
>
I frequently send JSON lists of data to my APIs...

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 precise as
> "non-elephant animals". barely better than NoSQL.
>
> I prefer to call each category by name.  in this case, "document-based
> storage".
>
>
You're singing my tune :)  But my issues with the "NoSQL" usage are (1) it
detracts from the existing project of that name , (2) it hides the true
intent of the "movement".  Hatred of SQL is a whole other bucket of bile :)

I do find it funny on many levels that people are raving about all these
other DB models as if they're new things :)

Anyway, this is OT... let's leave it for now :)

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 is "horses for courses".  If you need the strengths of a relational
store, use one.  If you need the benefits of any of the non-relational
models [and there are many - models, and strengths] use them.

But trying to shoe-horn a single API onto all models won't work.

However, if you'd rather build an Object Document Mapper [ODM] to provide a
consistent API for document databases, that could have some value.

--
Curtis

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




On 6 September 2013 06:12, Benjamin Zuill-Smith wrote:

> I've recently discovered Django and would love this framework in tandem
> with a NoSql solution like MongoDB. I know there is project called
> mongodb-engine but the solutions it brings feel hackish to me because it is
> not built into Django but added like middleware under the hood.  I'm weary
> of starting any real project using it. Are there any contributors out there
> considering adding native NoSql support? Plus, many NoSql solutions provide
> common functionality which could translate into a common interface which
> Django could provide.  I'd be interested to contribute to such an effort
> and I think it is worth looking into given the growth in NoSql solutions
> out there.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 there's little guessing involved.

However, I wouldn't want to see the same on Request, unless there was also
a direct way to imply the type you want.  For instance, if I get a request
that's in XML, and I ask for request.JSON, I'd like it to either yield
empty or raise an error.  Whereas when I didn't case, accessing
request.DATA would make a best guess.

So I see two paths... either you use a "Decode it for me according to
content-type" interface, or a "Treat is as this type, and fail predictably
if it's not" one.

The current GET/POST is, of course, the latter.  And there's no reason we
can't have both :)

--
Curtis



On 5 September 2013 04:06, Jonathan Slenders wrote:

> Would that mean that the object returned by request.DATA/POST/whatever
> could be a different type, depending on what the user posted?
>
> I don't want to see code like:
>
> if isinstance(request.DATA, YamlObject): ...
> elif isinstance(request.DATA, dict): ...
>
> although, I'm not sure how any view could handle any random content-type...
>
>
>
> Le mercredi 4 septembre 2013 13:57:29 UTC+2, Marc Tamlyn a écrit :
>>
>> The thing with request.POST is that it's kinda unintuitive when extended
>> to other HTTP methods (e.g. PUT). This is why the old request.raw_post_data
>> was renamed request.body.
>>
>> request.POST would behave in the expected traditional web way of picking
>> up form encoded POST data, which would also be available in request.DATA as
>> well, but request.DATA is the "new" way of doing it. Personally, I'd
>> lowercase it though, to remove confusion with the PHP $POST $GET $REQUEST
>> which we mimic on the request object. The generally have different use
>> cases anyway - one for complex web things and the other for standard web
>> browsers.
>>
>> (the above is what tom said...)
>>
>> Tom - what else do you have in DRF's Request that you would need?
>>
>>
>> On 4 September 2013 12:56, Tom Christie  wrote:
>>
>>> > Creating a request.DATA attribute would break compatibility with old
>>> code and seem to me less intuitive.
>>>
>>> The implementation would ensure `request.POST` would still be populated
>>> for form data.
>>>
>>> There wouldn't have to be any backwards incompatible changes, and usage
>>> of `request.DATA` (or whatever better name there might be, perhaps simply
>>> `request.data`) would be entirely optional for using with generic request
>>> parsing, instead of form data only.
>>>
>>>
>>> > Where should request.FILE go in that case
>>>
>>> request.FILES would be populated by form data as normal, and would be
>>> empty on JSON or other submissions.  In order to support multipart parsing
>>> the request parsing API would need to provide for parsers that support file
>>> upload, in a similar way that REST framework currently does.
>>>
>>> > Would request.POST just be a call to request.DATA?
>>>
>>> That's an open question, but I'd probably expect it to only return data
>>> if the request contains multipart or url-encoded form data.  (Ie. the
>>> behaviour wouldn't change.)
>>>
>>> Cheers,
>>>
>>>   Tom
>>>
>>> On Wednesday, 4 September 2013 12:33:00 UTC+1, Stefan Berder wrote:

 Tom,
 I agree that the middleware solution is not the best and in my mind
 creates fragmentation of the same type of request handling.

 A generic content-type framework would make the request parsing more
 flexible, stronger to change in the future and open the door to any type.

 I'm curious about the choice of request.DATA though, when doing a POST
 request, I expect the data to be in the POST dictionary and nowhere else.
 Creating a request.DATA attribute would break compatibility with old code
 and seem to me less intuitive. Where should request.FILE go in that case?
 Would request.POST just be a call to request.DATA?

 Stefan

 On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote:
>
> Hi Stefan,
>
> Sure, I'd be interested in seeing us improve how we deal with JSON
> requests and responses.
>
> My preference would be to introduce a request parsing and response
> rendering API that allows us to support not just JSON, but any media type
> that has a parser installed for it.  (I've commented on some of this
> before, 
> here,
> although I think I'm warming towards the idea that it's probably about 
> time
> we started addressing at least some of this in core.)
>
> Unsurprisingly I'd suggest the same general approach that 

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 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 existing content types are
> handled would be possible. [I haven't seen a use case for such yet, but
> it's a wild world out there :)]
>
> --
> Curtis
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 existing content types are handled
would be possible. [I haven't seen a use case for such yet, but it's a wild
world out there :)]

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


Re: get_cache and multiple caches

2013-09-01 Thread Curtis Maloney
Bit of a rambling, thinking-out-loud-ish post...

Whilst it's conceivable  some cache backend will have the smarts to
multiplex requests on a single connection, I suspect that's more the
exception than the case.

However, that doesn't mean the cache backend can't be left with the
opportunity to manage per-thread connections.  Obviously, the default would
be one per thread.

The situation is complicated with the "ad-hoc config" option.  Otherwise,
each cache backend could have a factory method, where the cares of thread
locality can be managed.  You'd just tell it the name, and it would take
care of the rest.

Of course, that could be simplified by just always creating a new instance
when more than just a name is provided. [or a "force new" keyword is
passed].

--
Curtis



On 1 September 2013 22:24, Florian Apolloner <f.apollo...@gmail.com> wrote:

> Hi,
>
>
> 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 existing API and behaviours are still available through
>> get_cache, but you can avoid duplicate instances of caches using
>> django.core.cache.caches[name]
>>
>
> As noted on the ticket (https://code.djangoproject.com/ticket/21012), I
> think this needs some more brainstorming (preferably on this ml) before we
> introduce a new pulbic API to access a cache. My main concern is: does it
> even make sense to share the cache connection between threads? eg what
> happens if two threads want to read a value from the cache, will one thread
> block till python-memcached returned the value for the other thread?
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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

--
Curtis



On 1 September 2013 17:00, Jorge Cardoso Leitao wrote:

> The way I stumbled across this problem was:
>
> 1. views imports models and forms (both are normally needed)
>
> 2. forms imports models (for ModelForm)
>
> 3. models imports views (for get_absolute_url), e.g.:
>
> *import views*
> *class MyModel(models.Model):*
> * get_absolute_url(reverse(views.myview))*
>
> which leads to a circular dependency of the form
> views->forms->models->views.
>
> I searched and there are some questions raised in stackoverflow about it,
> e.g. 
> this
> , this
> .
> This is avoided by removing one of the imports, and in this
> case the candidate is 3., replacing it with a string (e.g. 'views.myview').
>
> I propose that we add a note on the documentation of 
> get_absolute_url
> explaining that get_aboslute_url should be coded by returning reverses of
> strings and
> not of functions or classes to avoid circular dependencies.
>
> There is a ongoing 
> thread
>  about
> get_absolute_url and I think these problems are
> somewhat related: this circular dependency is a valid mistake from a
> Django user because models are depending on views, views on forms, forms
> on models.
>
> Another reason why I think this should be documented is that circular
> dependencies
> are difficult to debug, specially when they occur after modules are
> imported like *import module.*
>
> This also makes the documentation more consistent: Foreign 
> Key 
> already
> warns about circular dependencies:
>
> "This sort of reference can be useful when resolving circular import
> dependencies between two applications."
>
> In summary, I agree that the url's "anti-circular dependency" is correctly
> fixed from the implementation point of view by allowing strings,
> what I'm proposing is just to document why users should use it, i.e. what
> they are useful for, specially in the models' get_absolute_url.
>
> If no one objects, I can do this.
>
> Regards,
> Jorge
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 Maloney <cur...@acommoncreative.com> wrote:

> 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 <f.apollo...@gmail.com> wrote:
>
>> Hi,
>>
>> so when reviewing https://github.com/django/django/pull/1490/ I once
>> again ran over an issue with our current caching implementation: Namely
>> get_cache creates a new instance every time which is kind of suboptimal if
>> you don't store it as module level variable like we do with the default
>> cache. Are there any objections to make get_cache store those instances in
>> a dict and return those on request? It shouldn't cause to much problems,
>> since the current cache infrastructure expects you that you can share those
>> objects over multiple threads and requests anyways [And for caches which
>> don't support it like pylibmc we use threadlocals…]. Changing how get_cache
>> works could significantly reduce connections to the cache server depending
>> on how your views/templates are written.
>>
>> Thoughts?
>>
>> Cheers,
>> Florian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 https://github.com/django/django/pull/1490/ I once
> again ran over an issue with our current caching implementation: Namely
> get_cache creates a new instance every time which is kind of suboptimal if
> you don't store it as module level variable like we do with the default
> cache. Are there any objections to make get_cache store those instances in
> a dict and return those on request? It shouldn't cause to much problems,
> since the current cache infrastructure expects you that you can share those
> objects over multiple threads and requests anyways [And for caches which
> don't support it like pylibmc we use threadlocals…]. Changing how get_cache
> works could significantly reduce connections to the cache server depending
> on how your views/templates are written.
>
> Thoughts?
>
> Cheers,
> Florian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 the cache tag try to use a cache called "template_fragments" if
it exists, and otherwise use "default"

This is following on from the pattern established in staticfiles, where the
CachedFilesMixin will try to use a cache called "staticfiles" if available.

So far everyone involved agrees with (1)

However, the reception of (2) has so far been... luke warm.

So I was hoping for more eyes/input on this...

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Usage and documentation of F()

2013-08-19 Thread Curtis Maloney
Just a simple case of what I was talking about earlier, here's something we
used to avoid having to pass datetime.datetime.now() to a lot of timestamp
filtering queries:

class Now(ExpressionNode):
def __init__(self):
super(Now, self).__init__(None, None, False)

def evaluate(self, evaluator, qn, connection):
return 'CURRENT_TIMESTAMP', []

A little research shows this should work [almost] identically on all the
majors, and even Oracle and MS SQL.  The "almost" is become some will shift
the timestamp during a transaction, and others won't.

Now, how many other 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:
>
>> If, at the same time, perhaps ExpressionNode got a mention too, that
>> could really open up some opportunities :)
>
>
> Speaking of opportunities, here's a worthwhile ticket if we want to go
> further than docs for improving F():
>
> https://code.djangoproject.com/ticket/14030
>
>
> Cheers,
> AT
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.


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 from my
>> own possibly flawed understanding)
>>
>> The main point of using F is not generally for performance per se,
>> rather for database consistency. In the first example, the performance
>> increase is negligable, but you get two significant benefits. The first
>> is that you minimise the risk of race conditions by effectively issuing
>> "increment" rather than "set" to the database. The second is that you
>> can increase a number of rows the same way -
>> Product.objects.update(number_**sold=F('number_sold') + 1). These add
>> performance in that you end up doing fewer queries, but that's actually
>> what you're gaining.
>>
>> It is worth noting that the *only* reason to set an attribute to be an F
>> expression is to then update the value in the database. In fact, you
>> cannot access the value after you've done this, you get a
>> "django.db.models.expressions.**ExpressionNode" instance. In that sense,
>> doing product.number_sold = F('number_sold') + 1 is really a long hand
>> version of the update() query.
>>
>> As for what expressions are valid, I believe the things you suggested do
>> work, but I imagine exactly what works will depend on what operations
>> the database (and backend) support. Django itself isn't doing anything
>> clever here, it's just providing some architecture to allow you to
>> delegate functionality to the database.
>>
>> I agree that the main documentation for F() should reference the update
>> case (IMO as an update() rather than the longhand version).
>>
>> Marc
>>
>>
>> On 13 August 2013 20:22, Daniele Procida > > wrote:
>>
>> I noticed while looking for material for
>> 
>> >
>> that
>> > html#updating-attributes-**based-on-existing-fields/
>> >
>> mentions that:
>>
>>  product.number_sold = F('number_sold') + 1
>>
>> is faster than:
>>
>>  product.number_sold += 1
>>
>> though this doesn't seem to be mentioned in the database
>> optimisation page.
>>
>> That's easy enough to address, and
>> > optimization.html#do-database-**work-in-the-database-rather-**
>> than-in-python/
>> >
>> seems like a sensible place for it.
>>
>> However the mentions of F() that I did find raised a number of
>> questions.
>>
>> The F() class seems to be a handy general-purpose way to refer to
>> the value of a model field..
>>
>>
>> Firstly, it's not explained how, in expressions like:
>>
>>  product.number_sold = F('number_sold') + 1
>>
>> (from
>> > html#updating-attributes-**based-on-existing-fields/
>> >)
>> Django knows that F('number_sold') is refers to the product model.
>>
>> Does it know because product.number_sold is the field that this
>> expression refers to? What would happen if we did:
>>
>>  product.number_in_stock = F('number_in_stock') - F('number_sold)
>>
>> (i.e. can we make such calculations multiple other fields in one
>> go?), or:
>>
>>  product.number_to_reorder = F('number_sold)
>>
>> for example? What are the rules of the usage syntax of F()?
>>
>> Secondly, the main documentation for F()
>> > html#query-expressions/
>> >
>> doesn't mention this kind of use at all: it only suggests that it
>> might be useful in queries.
>>
>> Since this use seems to be just one of multiple uses for F(),
>> shouldn't a more general description of F() belong somewhere else
>> (where) instead?
>>
>>
>> Finally, are there any other useful ways to use F() not covered by
>> these two examples?
>>
>>
>> Daniele
>>
>
> I've always found the documentation on the usage of F() to be somewhat
> substandard compared to the rest of the documentation to the point were I
> rarely if ever use it.
>
> If the documentation could be beefed up I'm sure more people would be
> happy to use it in the general case rather than just small side cases.
>
>
> --
> You 

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 is that it's impossible
>> to
>> >clear the cached value. That should be mentioned in the docs.
>>
>> Better still -- if we're going to formalise this as a public API, lets
> update the implementation so that we *can* clear the cached value -- or at
> least document the method by which one would clear the cache. Lets not
> formalise a half-complete API :-)
>

I just ran some informal tests to compare it against my own
"buffered_property" implementation, and "del x.foo" deletes the cached
value just fine for me, as does "delattr(x, 'foo')".  Next access calls the
method again, as expected.  Also  "x.foo = 'test'" sets the value fine.

After our discussion on IRC today, Russ, I'm confident the current
implementation functions as you expect.


> One suggestion -- a new special topic guide on performance tweaking, just
> like we have for security. We've already got this page:
>
> https://docs.djangoproject.com/en/dev/topics/db/optimization/
>
> which is all about database optimisation -- this is a big part of
> optimising, but it's not the only story. A "performance" topic guide would
> give a chance to introduce value caching, template loading options
> (including cached templates), fast and slow session options, discussing how
> and when the database is hit, as well as little performance tweaks like the
> documented parts of utils.functional.
>
>
Hmm... I think I might have a few ideas to throw into that pile :)


> Russ %-)
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




Re: Security Advisory: BREACH and Django

2013-08-07 Thread Curtis Maloney
They don't try to guess the CSRF directly, AIUI.

They use a form field to affect their test.

The easiest solution I can see is the one mentioned in the document --
instead of outputting the raw value, output SALT || (SALT ^ TOKEN) so the
actual value is never in the response, but it can 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 403 response.
>
> Simon
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




Re: Streaming sitemaps

2013-07-25 Thread Curtis Maloney
On 26 July 2013 14:12, Roger Barnes <ro...@mindsocket.com.au> wrote:

> If you do want to go down the streaming path despite the caching, static
> and other advice, I can see a couple of options:
> 1) Write your own sitemap view that doesn't use the sitemap.xml template
> and instead streams back results using a StreamingHttpResponse and
> generator based get_url methods in sitemap classes. If that works out well,
> it might be an appropriate dropin replacement for the current view,
> although that would remove the availability of a customisable template.
>

Well, I was figuring that since sitemap is a XML based format, a generator
based rendering should be quite easy to achieve, even rendering a
template-per-record.


> 2) Ticket 13910 has a pull request to enable streaming templates, which
> would be a stepping stone to allowing refactoring of the existing sitemap
> view to stream a response using the template. The same caveat applies about
> whether this would improve memory usage or response-time performance if the
> sitemap urls are pre-calculated.
>

Ah, yes, I saw mindsocket working on  this at PyConAU sprints, but wasn't
sure how far through he'd got.  The issues I've had with generator
responses in the past is when there's an error in rendering, they tend to
just stop.

However, in the case of generating a stream of XML snippets, it's fairly
reliable.

--
Curtis




> - Roger
>
> [1] https://code.djangoproject.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 generator style SiteMap engine with a
>> StreamingHttpResponse.  It would allow the client to consume the data as
>> it's being consumed, instead of potentially timing out waiting for the
>> whole document to be generated.
>>
>> However, this may hide the growing problem for people whose sitemaps
>> gradually become large enough to warrant caching, but won't notice because
>> nothing is timing out, per se.
>>
>> Then again, micro-caching at the nginx/apache layer would also mitigate
>> the problem.
>>
>> --
>> Curtis Maloney
>>
>>
>>
>> On 25 July 2013 23:51, Benjamin Wohlwend <piqu...@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 lesson
>>> that large sitemaps shouldn't be rendered on demand. Since that day a few
>>> years ago, I always generate the sitemap periodically and let apache/nginx
>>> serve it. Recently, I even found a package that does all the heavy lifting
>>> for you: 
>>> https://github.com/**xaralis/django-static-sitemaps<https://github.com/xaralis/django-static-sitemaps>
>>>
>>> Kind regards,
>>> Benjamin
>>>
>>>
>>> On Thu, Jul 25, 2013 at 10:06 AM, julianb <julia...@gmail.com> wrote:
>>>
>>>> Since 1.5 we have streaming responses. What is the state of
>>>> contrib.sitemaps in this regard? I have some very large sitemaps and
>>>> experimented with making them faster a few years ago.
>>>>
>>>> If the do not yet stream, I think this would be a good idea to get
>>>> memory usage down. Is there anything to keep an eye on? Would it be
>>>> valuable to Django if this is looked into?
>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@**googlegroups.com.
>>>> To post to this group, send email to django-d...@**googlegroups.com.
>>>>
>>>> Visit this group at 
>>>> http://groups.google.com/**group/django-developers<http://groups.google.com/group/django-developers>
>>>> .
>>>> For more options, visit 
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@**googlegroups.com.
>>> To post to this group, send em

Re: Streaming sitemaps

2013-07-25 Thread Curtis Maloney
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 generator style SiteMap engine with a
StreamingHttpResponse.  It would allow the client to consume the data as
it's being consumed, instead of potentially timing out waiting for the
whole document to be generated.

However, this may hide the growing problem for people whose sitemaps
gradually become large enough to warrant caching, but won't notice because
nothing is timing out, per se.

Then again, micro-caching at the nginx/apache 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 lesson that large
> sitemaps shouldn't be rendered on demand. Since that day a few years ago, I
> always generate the sitemap periodically and let apache/nginx serve it.
> Recently, I even found a package that does all the heavy lifting for you:
> https://github.com/xaralis/django-static-sitemaps
>
> Kind regards,
> Benjamin
>
>
> On Thu, Jul 25, 2013 at 10:06 AM, julianb <julian@gmail.com> wrote:
>
>> Since 1.5 we have streaming responses. What is the state of
>> contrib.sitemaps in this regard? I have some very large sitemaps and
>> experimented with making them faster a few years ago.
>>
>> If the do not yet stream, I think this would be a good idea to get memory
>> usage down. Is there anything to keep an eye on? Would it be valuable to
>> Django if this is looked into?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




Re: Deprecate FCGI support in Django 1.7

2013-07-23 Thread Curtis Maloney
Well, mostly to indicate it's primary focus is on providing a FastCGI
server for Django.

I'm quite happy to keep it app agnostic, and be a general FastCGI->WSGI
publisher...


On 24 July 2013 15:04, Joe Tennies <tenn...@gmail.com> wrote:

> Is there a specific reason to call this "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, 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 2013 03:25, Some Developer <someukdevelo...@gmail.com> wrote:
>>
>>> On 22/07/13 10:00, Russell Keith-Magee wrote:
>>>
>>>> The hope is to start accelerating the release cycle slightly; however,
>>>> this also depends on someone actually doing the work :-)
>>>>
>>>
>>> Sounds good. I'd love to start helping with Django myself but I feel a
>>> bit lost when it comes to useful things to do. Maybe I'll start checking
>>> out the bug tracker and seeing what I can do there.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to 
>>> django-developers+unsubscribe@**googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
>>> .
>>> To post to this group, send email to django-developers@**
>>> googlegroups.com <django-developers@googlegroups.com>.
>>> Visit this group at 
>>> http://groups.google.com/**group/django-developers<http://groups.google.com/group/django-developers>
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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 2013 03:25, Some Developer  wrote:

> On 22/07/13 10:00, Russell Keith-Magee wrote:
>
>> The hope is to start accelerating the release cycle slightly; however,
>> this also depends on someone actually doing the work :-)
>>
>
> Sounds good. I'd love to start helping with Django myself but I feel a bit
> lost when it comes to useful things to do. Maybe I'll start checking out
> the bug tracker and seeing what I can do there.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> django-developers+unsubscribe@**googlegroups.com
> .
> To post to this group, send email to 
> django-developers@**googlegroups.com
> .
> Visit this group at 
> http://groups.google.com/**group/django-developers
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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 most often hear of, and it's generally their place to
implement the fork/thread/greenlet model used.



On 22 July 2013 02:39, Juan Luis Boya  wrote:

>
> Juan, technically Django isn't a server at all...
>>
>
> Django is a web application framework whose operation consists on waiting
> for HTTP requests from the network (encapsulated with WSGI) and replying
> each one of them with a HTTP response. Call it what you want.
>
>
>> whether it's sync, async, multi-threaded, multi-process, or a mix of any
>> of them is up to the wsgi publisher used.
>>
>
> This is what I understand with 'asynchronous' and 'synchronous' servers:
>
> * A synchronous server attends only one client connection at a time for
> each worker thread. Concurrency is achieved with operating system
> mechanisms like threads and processes.
> * An asynchronous server may be attending many client connections at a
> time for each worker thread. Concurrency is achieved within the thread
> using an application specific dispatcher. In an asynchronous server, there
> is only one blocking call accepted, which selects events from all
> connections. Typically this call is select(), epoll() or kqueue() depending
> on the system. **Other blocking calls must not be used because they would
> block the entire server until they return, preventing all available
> processing for other connections and thus killing server performance**.
> Therefore, asynchronous programming impose additional restrictions to the
> programmer, like:
>* Do not read or write files yourself, cause read() and write() are
> blocking by default. You must pass those operations through the dispatcher.
>* All database operations must pass through the dispatcher too. You
> can't block the thread until a SQL statement ends its execution.
>* All additional HTTP requests (like those to external APIs) must pass
> through the dispatcher too in order to not block the server until they are
> replied.
> and so on...
>
> There are also mixed approaches, i.e. an asynchronous load balancer which
> delivers new connections to synchronous worker threads or processes using
> IPC mechanisms.
>
> Since most (if not all) Django applications rely on blocking operations
> like those stated before, trying to make Django an asynchronous web
> platform expecting a huge performance improvement is a wrong idea. Putting
> that apart, the asynchronous load balancer (which can create and delete
> threads/processes depending on the server load) is not a bad idea.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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

> If you really want to get down and dirty with raw protocols have you
> considered an implementation that used epoll or kqueue for the networking?
> Combined with nginx as the front end HTTP server it should (theoretically)
> result in a huge increase in performance.
>

Well, that remains to be seen... it's early days yet, but I hope to be able
to support various work models.



> Basing the work on one of the Python async networking libraries (Twisted,
> Eventlet, gevent etc) should result in better performance and might well
> make FastCGI competitive with uWSGI and WSGI again. I really think that
> flup is the bottleneck when it comes to using FastCGI with Django. Having
> said that I haven't had a chance to look at the Django side of the code yet
> so there might be some optimisations that are possible there as well.


I wasn't aware there was a particular performance issue, but I'll certainly
keep it in mind.

Mostly, I was hoping to raise a new project to bear the burden of
maintenance, instead of Django core.  From what I've seen of late there's
various parts of the code which could be simplified if core assumes it's
only ever a WSGI app to be published.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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 21 July 2013 02:54, Juan Luis Boya  wrote:

>
> If you really want to get down and dirty with raw protocols have you
>> considered an implementation that used epoll or kqueue for the
>> networking? Combined with nginx as the front end HTTP server it should
>> (theoretically) result in a huge increase in performance.
>>
>> Basing the work on one of the Python async networking libraries
>> (Twisted, Eventlet, gevent etc) should result in better performance and
>> might well make FastCGI competitive with uWSGI and WSGI again. I really
>> think that flup is the bottleneck when it comes to using FastCGI with
>> Django. Having said that I haven't had a chance to look at the Django
>> side of the code yet so there might be some optimisations that are
>> possible there as well.
>>
>>
> AFAIK Django is not an asynchronous server, so each thread or process will
> handle only one connection at a time. That renders the asynchronous
> approach near useless.
>
> Correct me if I'm wrong.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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, Juan Luis Boya  wrote:

> For those who are keen to keep support for FastCGI, would you be
>> interested in helping me develop/maintain a Pure Python
>> FastCGI->WSGI(Django-specific) publisher package?
>>
>
> That exists and it's called flup. The code base is relatively small. What
> about simply forking it to something like flup2 and fixing the issues?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




Re: Deprecate FCGI support in Django 1.7

2013-07-18 Thread Curtis Maloney
For those who are keen to keep support for FastCGI, would you be interested
in helping me develop/maintain a Pure Python FastCGI->WSGI(Django-specific)
publisher package?

I agree it's valuable to have, as many have said [and I believe all have
agreed] but to keep it in core is unmaintainable.

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> wrote:
> > uWSGI + FastCGI: We should have nice docs about this.
>
>
> as others have previously said, uWSGI isn't viable for everybody.  is
> there any other pure-python fcgi-wsgi server with reasonable
> performance?
>
> i think several people like to use gunicorn for http-wsgi, if it (or
> something similar: flask? wep.py?, werkzeug?) supports fcgi, it could
> be the recommended fcgi solution.
>
>
> --
> Javier
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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 work:
>
> ProductEntry.objects.filter(lambda p: p.onpurchase_price * p.quantity
> == 5000.0)
>
> Or if you don't like the lambda keyword, extend the Q object. Something
> like this:
>
> ProductEntry.objects.filter(Q(onpurchase_price) * Q(quantity) == 5000.0)
>
>
ISTM it would be more of an extension of ExpressionNode, like F().

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




Re: Deprecate FCGI support in Django 1.7

2013-07-14 Thread Curtis Maloney
As much as I recognise FastCGI is pretty much a dead technology in the
Python world, for people stuck with cPanel sites like HostGator, it still
appears to be, pretty much, the only option.

And installing uWSGI there is simply not an option there.

So unless there's a pure python FastCGI -> WSGI 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 shared host (hostgator.com)
> and after lots of tries with wsgi only using fcgi was worked with
> apache2. but i will read and learn about uwsgi and try this. my app
> use version 1.6a of django is 1.6b worked using python 2.6. because
> parts of my app is with status development i will test this with
> python 2.7 too. but i agree that docs is not clear, because they mixed
> concepts of apache2 and django (directories static, admin etc). i am
> reviewing these docs soon for clarify concepts about wsgi, fcgi and if
> necessary uwsgi. If someone have advices or additional ref. is
> welcome! ;>)
>
> 2013/7/14 Florian Apolloner <f.apollo...@gmail.com>:
> > Hi,
> >
> > I'd like to get rid of everything FCGI-specific in Django sooner or later
> > (rather sooner). Flup isn't maintained since a long time and there is no
> > ticket tracker to report stuff. Graham pointed out that if someone wants
> to
> > use FCGI they can use
> > http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket
> > which doesn't even require flup, which sounds like a good compromise to
> me.
> > I'd need some help for the docs from some uWSGI users, since I have no
> idea
> > about it ;)
> >
> > Thoughts, objections?
> >
> > Cheers,
> > Florian
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
>
> --
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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 adds more magic, and the trend I'm seeing now in the IRC
channel is people are believing too much in magic.

Just my 0.000152 bitcoins...

--
Curtis


On 11 July 2013 13:51, Luke Sneeringer  wrote:

> What makes “name” special. Why not “label”, “title”, “code”, or any number
> of other things that people use internally?
>
> It also seems like you could solve this very easily by creating a stub
> model:
>
> from django.db import models
>
> class MyModel(models.Model):
> class Meta:
> abstract = True
>
> def __unicode__(self):
> return self.name
>
> This has the advantage of your not having to repeat yourself often (and it
> gives you another place to put your own particular things which you
> consistently practice), while not becoming opinionated about a naming
> scheme across the entire framework.
>
> Best Regards,
> Luke Sneeringer
>
> P. S. A place where I *would* love to see a better Django default would be
> in the __repr__ method.
>
> On Jul 10, 2013, at 9:46 PM, cmawebs...@gmail.com wrote:
>
> Hi All,
>
> Have you ever quickly set up a model, ran syncdb, and added a few sample
> objects in the admin to only see a bunch of "MyModel object"s in the
> changelist? I always forget to add a __unicode__()/__str__() method on my
> models.
>
> I ran "git grep -1 __unicode__" on some of my django projects and noticed
> a lot of repeated code. In fact, it seems that in about a _third_ of all my
> cases, I'm just returning self.name, or returning self.name would have
> been a good default. I looked at a few 3rd party apps for comparison and
> found similar results, though not for every app.
>
> IMHO, returning self.name (if the field or property exists) is a sensible
> default for __unicode__. We can still return "MyModel object" if there's no
> "name" attribute. You'll still end up adding your own __unicode__ method
> much of the time, just like you always have.
>
> Yes, it's "magic", but we can document it.
> Yes, it's a little more confusing, but we don't have to explain it during
> the tutorial.
> Yes, it's backwards incompatible, but only in rare cases should it be a
> problem.
> Yes, it could look like any Model without a "name" field is "wrong", but
> it's not.
> Yes, "title" is also very popular, but name is better. :)
>
> It has the effect of being a little more friendly in many cases, and can
> result in more DRY code.
>
> What do your __unicode__/__str__ methods look like? Is this a bad idea?
>
> Thanks,
> Collin
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




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 
table, but with one side being a 1to1.

ISTM that the sugar to make this behave wouldn't be much greater than that 
used for MTI, but I say that having not delved yet, so... what would I 
know? :)

--
Curtis


On Sunday, June 16, 2013 3:04:36 AM UTC+10, Carl Meyer wrote:
>
> Hi Amir,
>
> On Jun 15, 2013, at 9:11 AM, Amir Rachum  
> wrote:
>
> I'm not sure if this feature was discussed before (I've seen some mentions 
> of it when searching this group, but nothing definitive).
> I have written a blog post regarding the reasons (and the suggested 
> syntax) to use this relationship, and would love some feedback
>
>
> http://blog.amir.rachum.com/post/53019452363/a-case-for-a-onetomany-relationship-in-django
>
>
> The strongest reason not to do this is that it breaks the correspondence 
> between model fields and database columns. If you added a new OneToMany 
> field on Band pointing to Musician, suddenly the (unmodified) Musician 
> model's db table would require a schema migration, while the Band table 
> would remain unchanged. (Yes, ManyToManyField already sort of breaks this 
> correspondence, but only in that it causes a new table to be created in the 
> same app where you added the field. It never requires a schema migration 
> for an untouched model class, possibly in a different app, which is much 
> worse.)
>
> I think this downside alone is enough to kill the proposal for Django 
> core, especially considering the rationale in favor isn't that strong; it's 
> just a new way to spell the exact equivalent of a ForeignKey.
>
> That said, I'm pretty sure you could code this up outside of core, if 
> you'd like to experiment with it.
>
> Carl
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.




<    1   2   3