Re: 1.7 release status (RC2 coming soon)

[Curtis Maloney]

And for those who want to test, remember to use:

pip install git+https://github.com/django/django.git@stable/1.7.x

to ensure you're testing against 1.7 and not dev :)

--
Curtis




On 25 July 2014 09:42, Tim Graham  wrote:

> 2 weeks later and we still have a fairly strong stream of new bugs (thanks
> everyone for testing), so I wouldn't expect a second RC until next week at
> the earliest.
>
> There was a suggestion among the core team to release another RC (even if
> the list of release blockers isn't zero). This would make testing easier
> and help us avoid getting duplicate bug reports for issues fixed since RC1,
> but others were against it: "We should not release RC2 until there are 0
> release blockers, though - remember, an RC is supposed to be identical to
> the final release if there's no blockers." Opinions from the community on
> that would be welcome.
>
> On Thursday, July 10, 2014 5:49:10 PM UTC-4, Tim Graham wrote:
>>
>> It's been 2 weeks since the release of 1.7 RC1 and we've seen several
>> bugs opened and fixed, with several still open [1]. We plan to issue a
>> second RC sometime next week if we can empty that list. Help us fix the
>> issues if you have some time and keep testing!
>>
>> [1] https://code.djangoproject.com/query?status=assigned=new;
>> version=!master=Release+blocker=id=
>> summary=status=owner=type=component=
>> changetime=1=changetime
>>
>  --
> 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/89fb0487-7828-42e2-a85b-b63be9c28db8%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSAyOp5%3D9J6CsEcU68H9haJfw%2BFQFV09usEWhu%2BynjTEwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to use method based routing

[Curtis Maloney]

Sounds like you're heading for a cleaner version of the Publisher pattern
in django-nap...?


On 18 July 2014 07:34, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Hello,
>
> Currently implementing a method dispatcher (e.g. a single URL that
> goes to different views based on HTTP method) is not feasible because
> it will break decorators.
>
> For example:
> https://djangosnippets.org/snippets/2041/
>
> In theory you could use middleware to store the request object inside
> the view callback using process_view, or use frame/locals inspection
> on __getattr__ from your dispatcher, but these are all very nasty
> hacks.
>
> It would be nice if Django either had a built in way to do method
> based dispatching, or if base.py:get_response() was modified to pass
> over the request object somehow to the callback (although that doesn't
> feel particular clean either).
>
> The use case for this would be a REST API, in theory I could move the
> routing functionality into a view and decorate those methods, but then
> the decorators aren't really in the right place and routing logic is
> moved away from urls.py, which also feels unclean.
>
> I'm not sure what my proposal would be at this stage, if anyone else
> is interested lets get a dialog going,
>
> Cal
>
> --
> 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/CAHKQagE4RLvhLeJg%2BZPctd7FLv799mQnOgKFQEb2dTEfryheng%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSDfZOXvSfODHOXS3bdRoZvNLTw3py-yZF%2Bf17dCM9ephw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Curtis Maloney]

Can I ask as a favour to future works that you record all the performance
tuning approaches you use?

Many of these will be obvious to seasoned Python programmers, but some of
them won't be, and it would be nice to have a catalogue of "things to look
out for" to apply to critical paths in Django.

--
Curtis



On 5 July 2014 20:11, Josh Smeaton  wrote:

> Excellent work, well done. I have a couple of questions/ideas though.
>
> 1. The use of bit flags irks me. Would it be possible just to use numerous
> keyword arguments to the new get_fields ?
> 2. Since you've reduced the API to effectively two functions (get_fields,
> get_field), is it still necessary to contain those methods on an inner
> object? Can't the new methods live directly on the model? If they can't be
> put directly on the model for some reason, I would consider a better name
> than "meta". I can't think of a reason that the name meta should be used
> other than history. If you were to think about the purpose of the API
> without the associated history, what would you call it?
>
> log = Log.objects.get(pk=1)
> log.get_fields(concrete=True, m2m=True, related=True)
>
> log.get_field('log_level') # we're being explicit about the field name, no
> need for options
>
>
> Thoughts?
>
> I'll take a better look at the PR and see if I can offer anything with
> regards to your performance optimisations.
>
> Josh
>
> --
> 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/7496ef6d-4e88-41f4-b2b8-1bd2efa96aea%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSAnunv9t4GkJC7jha3Qy773eVDSL%2B9TACRAjqXDdyLuCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: collectstatic - override default ignore list

[Curtis Maloney]

OT...just writing down this which came to me on the train this morning as I
read this thread


Does anyone else foresee the practice of having an "appconfig.py" full of
subclasses of AppConfigs becoming common?

Seems like a nice parallel to settings, allowing a project to specify
per-app config overrides in a central location.  And lets us dispense with
per-app settings with faux namespaces...

--
C



On 3 July 2014 07:17, Andre Terra  wrote:

>
> On Wed, Jul 2, 2014 at 5:14 PM, Tomas Ehrlich 
> wrote:
>
>> I would really like to see app configs with app-specific settings.
>> Personally, I don't like flat settings where namespaces are created
>> with prefixes (eg. STATICFILES_ ).
>>
>> The idea of overriding class attributes in AppConfig seems promising.
>>
>
> I wholeheartedly agree. Flat settings in faux namespaces seems very
> unpythonic to me. Even though it should prove slightly more cumbersome to
> have to edit settings in many different files during development, having
> the correct place for each setting makes for a much more organized
> structure.
>
> Forgive me if this question sounds silly, but how would settings for, say,
> staticfiles be accessed from third-party apps? Would we still use from
> django.conf import settings? If not, then how would we know to look for
> 'acme.apps.AcmeStaticFilesConfig' or 'staticfiles'?
>
> Also, shouldn't something like the ignore_patterns list be included in a
> wrapper settings attribute of StaticFilesConfig? This way we could easily
> access settings through
> apps.get_app_config('some_app').settings['ignore_patterns'].
>
> Based on Thomas' proposal:
>
>
> class Command(BaseCommand):
> # ...
> def set_options(self, **options):
> # ...
> staticfiles_config = apps.get_app_config('staticfiles')
>
>
> -   self.ignore_patterns = staticfiles_config.ignore_patterns
>
>
> +   self.ignore_patterns = staticfiles_config.settings['ignore_patterns']
>
>
>
> Sorry if this is completely wrong! I'm a long time lurker and hobbyist,
> but not a developer by occupation.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKBiv3ygq-s7E2UkySW7ZEXEKZe5q1jOz9bhzy32ZCfc8316DQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSD5k7r8qSH3micGgHXwEwkJvHyg_y4FmYA-vfW-vj-fzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regression in ValidationError in 1.7

[Curtis Maloney]

Am I reading this right as "people used to commonly solve this problem by
using an internal API, but now we have a public one... AND the old internal
API is now changed"?

If so, the solution seems obvious -- document that it's time to move the
the official solution :)

--
Curtis



On 27 June 2014 21:04, Wim Feijen  wrote:

> Hi Russ,
>
> Good point and thanks for testing! For me, this should definitely be
> listed in the release notes and we should provide people a hint of how to
> fix it as well.
>
> IMO we do not need to support a non-documented feature.
>
> Wim
>
>
>
> On Friday, 27 June 2014 07:58:27 UTC+2, Russell Keith-Magee wrote:
>>
>> Hi all,
>>
>> I've just done some testing of 1.7 against my 'day job' code base. The
>> good news is that everything has pretty much worked out of the box without
>> any problems.
>>
>> However, I did find one regression, which I've opened as #22915 [1]. Full
>> details are on the ticket; the short version is that the API for
>> Validation.update_error_dict() has changed in very subtle way. The change
>> was introduced by [2], which introduced Form.add_error() [3].
>>
>> The catch here is that ValidationError is definitely stable API, but
>> update_error_dict isn't documented - so it isn't clear to me whether this
>> should be considered a regression in a stable API that must be fixed, or a
>> "backwards compatibility gotcha" that is worth some documentation, but not
>> a code change.
>>
>> I caught the problem running the test suite for my "day job app". I'm
>> doing some moderately complex form error handling, and in the `clean()`
>> method for a form, I'm raising an error against a specific field on the
>> field. This appears to be the exact use case that the `Form.add_error()`
>> API is designed to satisfy, so the regression has been introduced by adding
>> a formal API for something that people (including myself) would have been
>> doing previously in an ad-hoc fashion.
>>
>> The question here is whether we need to continue to support the ad-hoc
>> usage in a backwards compatible way.
>>
>> Thoughts?
>>
>> Yours,
>> Russ Magee %-)
>>
>> [1] https://code.djangoproject.com/ticket/22915
>> [2] https://github.com/django/django/commit/
>> f563c339ca2eed81706ab17726c79a6f00d7c553
>> [3] https://code.djangoproject.com/ticket/20867
>>
>  --
> 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/841bccb0-3251-47e1-bc53-27413d052506%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSC9afJOUCuwT-%2B4_QncQ8OW_pLFsqH1E4Lfj3n2hHyTfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Curtis Maloney]

Is there somewhere I can look at your work in progress code?


On 21 June 2014 19:57, Daniel Pyrathon  wrote:

> Hi All,
>
> This week I have done the following
>
> *- Openend PR and merged Options (_meta) unittests*
> https://github.com/django/django/pull/2823
> This is a working test suite of model/options.py file. Is is currently
> testing the current Options implementation.
>
> *- Re-implemented test-suite in the new API*
> My new proposed API has been implemented on top of the Options unittests.
> This means new and old API give the same results! and therefore the new API
> is a working re-implementation.
>
>  *- Performance optimizations*
> Currently, the biggest issue I have had (in the new API) regards
> performance. I am doing small optimisations and benchmarking with cProfile.
> If anyone has some good hints on how to benchmark single functions in
> Django please let me know!
>
> Regards,
> Dan
>
>
> On Friday, June 13, 2014 10:11:41 PM UTC+2, Aymeric Augustin wrote:
>
>> I like this simplification a lot. I hope you can make it work.
>>
>> Just check that you don’t "overload" fields, by storing in field objects
>> information that doesn’t belong there.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 13 juin 2014, at 19:53, Daniel Pyrathon  wrote:
>>
>> Hi All,
>>
>> This week's work was a follow-up of last week's work, with some new
>> discoveries with regards to the new API:
>>
>> *1) Improved the current _meta implementation of unittests*
>> I refactored the current meta unittest branch into a more compact
>> version. I also added test cases for Generic Foreign Keys, RelatedField and
>> more improvements on virtual fields. This section will actually be our
>> first merge to master: a unit test suite for the current implementation.
>>
>> This branch is found here: https://github.com/
>> PirosB3/django/tree/soc2014_meta_unittests
>>
>> *2) Refactored the new _meta API spec*
>> By implementing the new API, I found new redundancies in the current
>> implementation that we can avoid in the new API spec:
>>
>> *1) Only return field instances*
>> the current implementation has a common return pattern: (field_object,
>> model, direct, m2m). After a few tests I realized that model, direct, m2m
>> and field_name are all redundant and can be derived from only field_object.
>> Since there are only 3-4 places that actually use direct and m2m it makes
>> sense to remove this function from the new API spec.
>> Here I show how all the information can be derived form field_instance (
>> https://gist.github.com/PirosB3/6cb4badbb1b8c2e41a96/revisions), I ran
>> the entire test suite and things look good. The only issue I can see now is
>> from a performance point of view.
>>
>> *2) Provide only 2 API endpoints*
>>
>>  - get_fields(types, opts) -> (field_instance, field_instance, ...)
>>  - get_field(field_name) -> field_instance
>>
>> The rest is all (I might be very wrong! don't trust me) redundant. By
>> continuing with this iterative approach, I will soon find out if I am
>> correct or not ;)
>>
>>
>> This branch is found here: https://github.com/
>> PirosB3/django/tree/soc2014_meta_refactor
>>
>> For any questions, as usual, let me know
>> Dan
>>
>>
>> On Friday, June 6, 2014 7:03:36 PM UTC+2, Daniel Pyrathon wrote:
>>>
>>> Hi All,
>>>
>>> Based on the work done last week, this week I have worked on the
>>> following:
>>>
>>> *1) Covered the current _meta implementation of unittests*
>>> The current Options is not covered by unit tests at all, I have created
>>> the model_options test module containing one or more unit tests for each
>>> endpoint and usage. Each endpoint is tested with many different models and
>>> fields (data, m2m, related objects, related m2m, virtual, ..). Each unit
>>> test asserts equality in field naming and field type. Endpoints that return
>>> the model are also tested for equality.
>>>
>>> This branch is found here: https://github.com/
>>> PirosB3/django/tree/soc2014_meta_unittests
>>>
>>> *2) Pulled in tests from soc2014_meta_unittests and tested the new
>>> implementation*
>>> The previous branch that I developed on contains the new API
>>> implementation, I have pulled in the tests from soc2014_meta_unittests and
>>> I have switched the old API calls to the new API calls (with a few
>>> adjustments). I have successfully made all tests pass even though I have
>>> found some design issues that need to be addressed in my next update call.
>>>
>>> This branch is found here: https://github.com/
>>> PirosB3/django/tree/soc2014_meta_refactor
>>>
>>> *3) Created a new branch that maps the old implementation with the new*
>>> Today I started putting my new API in "production". This is obviously
>>> nowhere near a finalised version but it helps me spot some edge cases that
>>> are not in the unit-tests. Each issue found has been converted into a
>>> standalone unit-test and has been proved to fail.
>>> Unfortunately, this made me realise of other design issues 

Re: Building a library of SQL functions into Django

[Curtis Maloney]

Would it be possible to have some sort of registration pattern, allowing
people to import per-backend and per-project libs to override and extend
the various available functions?

I realise this is nothing more than a sanctioned form of monkey patching,
but it would at least provide a common pattern for people to do so, and
hopefully make the whole process more manageable and predictable.

--
Curtis



On 18 June 2014 17:09, Anssi Kääriäinen  wrote:

> On Wednesday, June 18, 2014 4:52:11 AM UTC+3, Josh Smeaton wrote:
>>
>> Over the last 6 months we've been working on a fairly large refactor to
>> expressions. As a brief catch up, expressions are currently F()
>> expressions. I've expanded their scope to include Aggregates. As a
>> by-product of this we can now use any kind of expressions in the
>> .annotate() function, not just aggregates. Tim Martin has done some work
>> based on this patch that extends support to .order_by() also. See the
>> bottom of this post for links to the various discussions and patches. I
>> highly recommend reading them - and for 3rd party backend maintainers -
>> trying them out.
>>
>
> Not just 3rd party backend maintainers, but also for 3rd party library
> writers. The new way could break your code if you depend on current
> implementation of ExpressionNode, aggregates or SQLEvaluator.
>
> I think finding a small subset of commonly used functions and including
> them in core or contrib is a good idea - these should be building blocks
> every Django application can depend on. The main problem is how to limit
> that subset.
>
> 5. Are we jumping the gun and should we wait until the patches land before
>> even discussing the above?
>>
>
> Maybe a bit - maybe it is better to wait and see what happens to the
> expressions refactor idea. It is interesting to see that the expressions
> refactor patch has led to multiple discussions about how to use it for
> other new features. So, expressions refactor is definitely doing something
> right.
>
>  - 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/daf867fe-bedf-4134-bc92-728e2fa2c17f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSCQucYt98Vyzdt_TiQDSiFrr%3D4rLpSmDbHXbxWv%2B6_P%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrating polymorphic queries in the framework

[Curtis Maloney]

Hosted version of the talk:
http://www.roadside-developer.com/talks/2013-12-12_MelbDjango_MTI.Performance/#/

[Thanks, Brenton!]

--
Curtis



On 7 June 2014 11:52, Curtis Maloney <cur...@acommoncreative.com> wrote:

> Can I draw your attention to Sebastian Vetter's investigation of the
> relative scalability of different model polymorphism approaches :
> https://github.com/elbaschid/talks/tree/master/2013-12-12_MelbDjango_MTI.Performance
>
> Basically, the "select_related then resolve" approach [used in
> django-model-utils InheritanceManager] doesn't scale nearly as well as
> django-polymorphic's more pre-fetch-related "1+N queries" approach.
>
> --
> Curtis
>
>
> On 7 June 2014 01:00, Luis Masuelli <luisfmasue...@gmail.com> wrote:
>
>> Don't know if it's a big patch at all. A polymorphic call could be like
>> this:
>>
>> 1. Check if the class is polymorphic by itself or by inheritance:
>>
>> Traverse the inheritance D-Graph (we have to remember it's not a tree
>> anymore) starting from the current class - It would stop on (and not count)
>> models.Model (abstract=True and proxy models are also not counted). It
>> should stop on the first parent having a Meta definition as I exposed
>> before.
>> Having multiple (concrete) ancestors defining a Meta like that, would
>> raise an exception.
>> Defining such Meta while an ancestor already defined it, would raise the
>> same exception.
>> Not finding such Meta in the dgraph would have no effect, and the entire
>> process would be ignored (i.e. a norma query could be executed over the
>> current model). It could alternatively throw an exception or leave it as a
>> settings option (CONTENTTYPE_POLYMORPHIC_EXCEPTION = True #you get the idea)
>>
>> 2. If the Meta was found, the polymorphic query could be done. Traverse
>> the models down from the initial model class (i.e. the one from which the
>> PQ was done on) enumerating concrete and nonproxy models. Basing in your
>> idea, a narrow=(Model1, Model2, ...) argument could be specified to only
>> include those models in the list, ignoring the rest (and stopping when all
>> those model classes were iterated and found). As complement, an
>> exclude=(Model1, Model2) could be alternatively specified to skip those
>> classes (as skipping proxy and abstract classes in the enumeration).
>>
>> 3. Perform a select_related or prefetch_related query with the enumerated
>> classes. This would do a join or prefetch perhaps only on the classes of
>> interest (narrow=/exclude=) instead of doing the biggest possible join.
>>
>> An alternative could be that to define a polymorphic model, the parent
>> model could be a brand new contenttypes.models.PolymorphicModel (itself
>> being abstract=True) and the nearest concrete ancestors must implement such
>> Meta attributes (or an exception should be throw). Perhaps this (abstract)
>> model could have a metaclass defining a new Manager for 'objects' attribute
>> which could generate a queryset implementing this polymorphic() method.
>>
>> Such model could have the widely-mentioned get_real_instance (as in
>> django-polymorphic) or narrow() as mentioned in the post. The
>> implementation could vary: it starts by getting the current object's
>> contenttype from the discriminator and get the model class for it. if
>> narrow-style is implemented, issubclass() could be called to determine
>> whether the object belongs to any of those classes and return the real
>> instance if so (it could avoid loading a non-specified class lazily).
>> implementing get_real_instance class could load lazily the class if was not
>> specified.
>>
>> As I see, an implementation like I described (which is not new at all)
>> could let you leverage the polymorphism level and let you suffer the
>> tradeoffs you choose.
>>
>> Remember that, with this (rant-styled, but improved from reading the post
>> you pointed me to) proposal, anyone could choose to use the polymorphism in
>> the queries or not, by calling explicitly such method on the query. Not
>> using it would behave as normal queries.
>>
>>
>>
>> El jueves, 5 de junio de 2014 20:03:14 UTC-5, Russell Keith-Magee
>> escribió:
>>
>>>
>>> On Fri, Jun 6, 2014 at 6:49 AM, Luis Masuelli <luisfm...@gmail.com>
>>> wrote:
>>>
>>>> What about integrating polymorphic features in the ORM? It's like
>>>> having the features of django-polymorphic but in the core.
>>>>
>>>> The polymorphism could be acheved by:
>>>> 1. Hav

Re: Integrating polymorphic queries in the framework

[Curtis Maloney]

Can I draw your attention to Sebastian Vetter's investigation of the
relative scalability of different model polymorphism approaches :
https://github.com/elbaschid/talks/tree/master/2013-12-12_MelbDjango_MTI.Performance

Basically, the "select_related then resolve" approach [used in
django-model-utils InheritanceManager] doesn't scale nearly as well as
django-polymorphic's more pre-fetch-related "1+N queries" approach.

--
Curtis


On 7 June 2014 01:00, Luis Masuelli  wrote:

> Don't know if it's a big patch at all. A polymorphic call could be like
> this:
>
> 1. Check if the class is polymorphic by itself or by inheritance:
>
> Traverse the inheritance D-Graph (we have to remember it's not a tree
> anymore) starting from the current class - It would stop on (and not count)
> models.Model (abstract=True and proxy models are also not counted). It
> should stop on the first parent having a Meta definition as I exposed
> before.
> Having multiple (concrete) ancestors defining a Meta like that, would
> raise an exception.
> Defining such Meta while an ancestor already defined it, would raise the
> same exception.
> Not finding such Meta in the dgraph would have no effect, and the entire
> process would be ignored (i.e. a norma query could be executed over the
> current model). It could alternatively throw an exception or leave it as a
> settings option (CONTENTTYPE_POLYMORPHIC_EXCEPTION = True #you get the idea)
>
> 2. If the Meta was found, the polymorphic query could be done. Traverse
> the models down from the initial model class (i.e. the one from which the
> PQ was done on) enumerating concrete and nonproxy models. Basing in your
> idea, a narrow=(Model1, Model2, ...) argument could be specified to only
> include those models in the list, ignoring the rest (and stopping when all
> those model classes were iterated and found). As complement, an
> exclude=(Model1, Model2) could be alternatively specified to skip those
> classes (as skipping proxy and abstract classes in the enumeration).
>
> 3. Perform a select_related or prefetch_related query with the enumerated
> classes. This would do a join or prefetch perhaps only on the classes of
> interest (narrow=/exclude=) instead of doing the biggest possible join.
>
> An alternative could be that to define a polymorphic model, the parent
> model could be a brand new contenttypes.models.PolymorphicModel (itself
> being abstract=True) and the nearest concrete ancestors must implement such
> Meta attributes (or an exception should be throw). Perhaps this (abstract)
> model could have a metaclass defining a new Manager for 'objects' attribute
> which could generate a queryset implementing this polymorphic() method.
>
> Such model could have the widely-mentioned get_real_instance (as in
> django-polymorphic) or narrow() as mentioned in the post. The
> implementation could vary: it starts by getting the current object's
> contenttype from the discriminator and get the model class for it. if
> narrow-style is implemented, issubclass() could be called to determine
> whether the object belongs to any of those classes and return the real
> instance if so (it could avoid loading a non-specified class lazily).
> implementing get_real_instance class could load lazily the class if was not
> specified.
>
> As I see, an implementation like I described (which is not new at all)
> could let you leverage the polymorphism level and let you suffer the
> tradeoffs you choose.
>
> Remember that, with this (rant-styled, but improved from reading the post
> you pointed me to) proposal, anyone could choose to use the polymorphism in
> the queries or not, by calling explicitly such method on the query. Not
> using it would behave as normal queries.
>
>
>
> El jueves, 5 de junio de 2014 20:03:14 UTC-5, Russell Keith-Magee escribió:
>
>>
>> On Fri, Jun 6, 2014 at 6:49 AM, Luis Masuelli 
>> wrote:
>>
>>> What about integrating polymorphic features in the ORM? It's like having
>>> the features of django-polymorphic but in the core.
>>>
>>> The polymorphism could be acheved by:
>>> 1. Having contenttypes installed (this is a common pattern).
>>> 2. Specifying a root (first ancestor) model class like:
>>>
>>> class MyParentModel(models.Model):
>>> ...
>>>
>>> class Meta:
>>> polymorphic = True
>>> discriminant = "somefield" #it could default to
>>> 'content_type' if not specified. This field could be created.
>>>
>>> To achieve the polymorphism a query could be like:
>>>
>>> objects = MyParentModel.objects.filter(foo=bar,baz=clorch,...).
>>> polymorphic().more().calls().ifneeded()
>>>
>>> Such method could complain if the contenttypes application is not
>>> installed; it could be based on many select_related() arguments (which are
>>> collected by tree-traversing the hierarchy, perhaps ignoring proxies).
>>> Alternatively, this could be an util in the contenttypes app instead of
>>> the core 

Re: Revisiting multiline tags

[Curtis Maloney]

Now taking input and feedback:

https://github.com/funkybob/deps/blob/master/drafts/multiline_tags.rst


On 16 April 2014 14:15, Loic Bistuer <loic.bist...@sixmedia.com> wrote:

> On Wednesday, April 16, 2014 10:36:00 AM UTC+7, Adrian Holovaty wrote:
>>
>> Hey, may I suggest writing this up using our new DEP process? I don't
>> mean to make people jump through hoops, but it would be useful for people
>> like me who haven't been following the issue and don't want to wade through
>> dozens of mailing-list messages, comment threads, patches, etc.
>>
>
> I agree, DEP seems to be the best tool for this kind of proposals and
> design decisions. Even more so now that Curtis volunteered to write it :P
>
> Note that me asking for a DEP doesn't mean I necessarily support the idea
>> of multiline tags -- the point of a DEP is to collect and organize thoughts
>> in one place, not to be a "we will definitely do this" feature plan.
>>
>
>
> Understood, a DEP can be accepted or rejected.
>
> On Wednesday, April 16, 2014 10:48:22 AM UTC+7, Curtis Maloney wrote:
>
>> I'm happy to coalesce this into a DEP... is there a format template I can
>> follow?
>>
>
> I believe https://github.com/django/deps/blob/master/deps/0001.rst serves
> as a template? Thanks for offering to work on it.
>
> --
> Loic
>
> --
> 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/07a50d8f-4b4b-4917-aa31-662c0376943d%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/07a50d8f-4b4b-4917-aa31-662c0376943d%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSDQPiKSXt-5WNCi_rMoJ%2BBDwGi7yMbqvMyiO8Yhp9OkFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

I'm happy to coalesce this into a DEP... is there a format template I can
follow?


On 16 April 2014 13:46, Russell Keith-Magee  wrote:

> On Wed, Apr 16, 2014 at 11:36 AM, Adrian Holovaty 
> wrote:
> > Hey, may I suggest writing this up using our new DEP process? I don't
> mean
> > to make people jump through hoops, but it would be useful for people
> like me
> > who haven't been following the issue and don't want to wade through
> dozens
> > of mailing-list messages, comment threads, patches, etc.
> >
> > Here's more info: https://github.com/django/deps Just make a new text
> file
> > and send as pull request when you're done.
> >
> > Note that me asking for a DEP doesn't mean I necessarily support the
> idea of
> > multiline tags -- the point of a DEP is to collect and organize thoughts
> in
> > one place, not to be a "we will definitely do this" feature plan.
>
> … and, more importantly from the long term perspective: if we
> ultimately decide to say "we *won't* do this", it provides a clear
> place we can point with the reasons why.
>
> 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/CAJxq848yJwfrGtvY-Uta3e-1ooQb5J56SZXjru_yeOC%3DjzzLBw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSASgP74Dz6x8JUWk1WD-7W6eq1LM2%3DVLgh1_cp_2SR%2BEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

Would it help if I said please?


On 4 April 2014 11:29, Curtis Maloney <cur...@acommoncreative.com> wrote:

> Have any of you tested my code which gives you multi-line tags?
>
> I'd be interested in hearing how it fares "in the real world"
>
> --
> C
>
>
>
> On 4 April 2014 01:52, dude <y...@helldude.ru> wrote:
>
>> More useful example is not ‘very long with’, just a situation with html
>> code block, which have in left sir already offset about 60 cols. And when
>> we add there any django template tag with params it goes exceed 80 lines
>> (for standard). But we can use 120 of course. In real life html tree can be
>> very deep. Html tags can be multilines and this is awesome when you want
>> make deep tree good looking, but dj templates  not support it.
>>
>> If django can support multiline it would be great i think and community
>> will like this feature immediately.
>>
>> 03 апр. 2014 г., в 21:29, Daniel Ellis <ellis...@gmail.com> написал(а):
>>
>> Hmm, that does seem like a great idea!
>>
>>
>> On Thu, Apr 3, 2014 at 10:17 AM, dude <y...@helldude.ru> wrote:
>>
>>> Very good idea i think!
>>>
>>> Many people love format source codes to be beauty. But they can’t
>>> because django templates does’t support multiline tags.
>>>
>>>
>>> 03 апр. 2014 г., в 21:13, Daniele Procida <dani...@vurt.org> написал(а):
>>>
>>> > On Thu, Apr 3, 2014, Carl <c...@supervacuo.com> wrote:
>>> >
>>> >> As someone said earlier in the thread, making Python programmers deal
>>> with
>>> >> long lines seems like some special form of torture ;)
>>> >
>>> > My own use case is this:
>>> >
>>> > {% with placeholder_width=960 generic_main_width=523
>>> sidebar_image_size="294x196" entity_image_size="445x384"
>>> entity_map_size="445x100" person_map_size="445x100"
>>> sidebar_map_size="296x100" person_image_size="460x460"
>>> person_thumbnail_size="40x40" lightbox_max_dimension=600
>>> plugin_thumbnail_size="75x75" place_image_size="627x418"
>>> place_map_size="294x182" body_heading_level=2 %}
>>> >
>>> > Now that's very horrible to read.
>>> >
>>> > This would be much nicer:
>>> >
>>> > {% with
>>> >placeholder_width=960
>>> >generic_main_width=523
>>> >sidebar_image_size="294x196"
>>> >entity_image_size="445x384"
>>> >entity_map_size="445x100"
>>> >person_map_size="445x100"
>>> >sidebar_map_size="296x100"
>>> >person_image_size="460x460"
>>> >person_thumbnail_size="40x40"
>>> >lightbox_max_dimension=600
>>> >plugin_thumbnail_size="75x75"
>>> >place_image_size="627x418"
>>> >place_map_size="294x182"
>>> >body_heading_level=2
>>> > %}
>>> >
>>> > And yes, there is a good reason for wanting to use {% with %} in this
>>> way!
>>> >
>>> > 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.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
>>> .
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>
>> --
>> 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/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>

-- 
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_XiSBY4bg85wcHPsgW0JGUoadjz0KEKMzL%3DGNAno%3DTp6rHTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

Have any of you tested my code which gives you multi-line tags?

I'd be interested in hearing how it fares "in the real world"

--
C



On 4 April 2014 01:52, dude  wrote:

> More useful example is not ‘very long with’, just a situation with html
> code block, which have in left sir already offset about 60 cols. And when
> we add there any django template tag with params it goes exceed 80 lines
> (for standard). But we can use 120 of course. In real life html tree can be
> very deep. Html tags can be multilines and this is awesome when you want
> make deep tree good looking, but dj templates  not support it.
>
> If django can support multiline it would be great i think and community
> will like this feature immediately.
>
> 03 апр. 2014 г., в 21:29, Daniel Ellis  написал(а):
>
> Hmm, that does seem like a great idea!
>
>
> On Thu, Apr 3, 2014 at 10:17 AM, dude  wrote:
>
>> Very good idea i think!
>>
>> Many people love format source codes to be beauty. But they can’t because
>> django templates does’t support multiline tags.
>>
>>
>> 03 апр. 2014 г., в 21:13, Daniele Procida  написал(а):
>>
>> > On Thu, Apr 3, 2014, Carl  wrote:
>> >
>> >> As someone said earlier in the thread, making Python programmers deal
>> with
>> >> long lines seems like some special form of torture ;)
>> >
>> > My own use case is this:
>> >
>> > {% with placeholder_width=960 generic_main_width=523
>> sidebar_image_size="294x196" entity_image_size="445x384"
>> entity_map_size="445x100" person_map_size="445x100"
>> sidebar_map_size="296x100" person_image_size="460x460"
>> person_thumbnail_size="40x40" lightbox_max_dimension=600
>> plugin_thumbnail_size="75x75" place_image_size="627x418"
>> place_map_size="294x182" body_heading_level=2 %}
>> >
>> > Now that's very horrible to read.
>> >
>> > This would be much nicer:
>> >
>> > {% with
>> >placeholder_width=960
>> >generic_main_width=523
>> >sidebar_image_size="294x196"
>> >entity_image_size="445x384"
>> >entity_map_size="445x100"
>> >person_map_size="445x100"
>> >sidebar_map_size="296x100"
>> >person_image_size="460x460"
>> >person_thumbnail_size="40x40"
>> >lightbox_max_dimension=600
>> >plugin_thumbnail_size="75x75"
>> >place_image_size="627x418"
>> >place_map_size="294x182"
>> >body_heading_level=2
>> > %}
>> >
>> > And yes, there is a good reason for wanting to use {% with %} in this
>> way!
>> >
>> > 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.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/20140403141333.1946415207%40smtpauth.cf.ac.uk
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> 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/CAJGew6%3Drht8nSrVibSpmpz%3DQK-cunjPHup6TBXvYAY6GPWXg3g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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_XiSCpn00fDjEJmrs%3DwK8Kx8q4EG0jj8R0ma246n746Pi1Fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for prepared statements API

[Curtis Maloney]

On 27 March 2014 19:11, VernonCole  wrote:

> There was a recent query about prepared statements on the db-sig mailing
> list, too. Apparently thought is being given to adding such functionality
> to Psycopg. If such functionality is added, it could be useful to support,
> I suppose. Some SQL engines apparently benefit from the techinque. MS SQL
> Server is not one of them, so I have not bothered to add support for them
> to adodbapi.  If I do so, it will use the same api as mxodbc uses now (a
> copy of the SQL statement is kept with the cursor). [note: my reading of
> Microsoft's recommendation is not "don't do that", it is "why bother?".]
>
> Pep-0249 is silent on the subject of how to support prepared statements,
> so any existing systems are likely to do so differently.  In particular,
> there can be no expectation that there is any support whatsoever for the
> concept, so it will have to be emulated where not present (-- i.e. almost
> everywhere).
>

Yeah... the only places PEP 249 mentions prepare is in execute and
executemany... where I'm fairly sure almost no drivers do "prepare and
execute".

As for lack of existing support, I suspect there's a degree of "if you
build it, they will come" to this... worst case is to simply implement it
as raw SQL.

--
C

-- 
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_XiSAswQGnPFvYE4ugYN1sKpL%2B7PKF4t8%2BGBuoKJoU28JV8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for prepared statements API

[Curtis Maloney]

On 26 March 2014 10:10, Florian Apolloner <f.apollo...@gmail.com> wrote:

> On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote:
>>
>> Firstly -- can we assume anyone using this feature is not a complete
>> novice, and so will take the caveats mentioned into consideration?
>>
>
> Yes
>
>
>> Yes, prepared statements are local to their connection/session.  And
>> would be expected to "go away" should the connection drop.  However, in
>> most cases connection drop-out is quite rare [at least, in my experience],
>> and would be even more rare in the case of people using certain connection
>> pooling tools.
>>
>
> Assume connection drops don't exist for now. How can/will Django know if a
> query is prepared already and when does it have to prepare it, or do you
> expect me to issue a PREPARE statement everywhere I use it and handle the
> error if it already exists?! I can easily see this working for management
> scripts, but not for web requests which are possible routed through pgpool
> etc… [That said, I have no real experience with those things, but I'd like
> to know how this can work]
>

I had been working from the perspective that as soon as you call prepare()
on the QuerySet, it will prepare the statement.

I can find some bug reports for pgpool to do with unnamed prepares, but
[oddly] can't find docs about unnamed prepares.

Even if the first implementation is simply: Provide the API, document the
caveats, it's at least a good first step upon which we can test how the
various drivers support it, dbs interact, and error conditions explode.


> Assuming it's not fatal to a transaction, would it be feasible for a
>> prepared statement to work on the assumption is has been prepared, and if
>> it hasn't, prepare itself and continue?  I'd prefer this to, for instance,
>> having PS listen for connection closed signals.
>>
>
> See above, how can you reliable determine if this assumption holds up?
>

As they say in electricians school: suck it and see. :)


>
> Further, as an "expert" feature, would it be unreasonable to limit its use
>> to cases where you know it will benefit, but also only be used in a single
>> connection?  True, this limits its use cases somewhat, but it's still
>> available when of benefit.
>>
>
> What do you mean by "single connection", persistent connections are single
> connections and as you said above prepared statements are local to the
> connection/session anyways…
>

And I would expect the prepared statement to persist between requests in
that case.

If I thought we could rely on DB dis/connect signals [maybe we can, I don't
know yet] we could teach prepared statements to track that and re-prepare
themselves  on first use.

Just throwing ideas out there... seeing which ones excite :)

--
C

-- 
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_XiSCN%2BOOV%3Drmr86vkXL8MwycSjjHRfJbMuGkVnXF1D0F72g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for prepared statements API

[Curtis Maloney]

Firstly, I mostly proposed this API in response to others calls for it.
 Yes, I'd love to have it, but I'm content to leave it in the "too hard"
basket.

That said, it doesn't mean I'm not going to try to solve these issue :)

So:

Firstly -- can we assume anyone using this feature is not a complete
novice, and so will take the caveats mentioned into consideration?

Yes, prepared statements are local to their connection/session.  And would
be expected to "go away" should the connection drop.  However, in most
cases connection drop-out is quite rare [at least, in my experience], and
would be even more rare in the case of people using certain connection
pooling tools.

Assuming it's not fatal to a transaction, would it be feasible for a
prepared statement to work on the assumption is has been prepared, and if
it hasn't, prepare itself and continue?  I'd prefer this to, for instance,
having PS listen for connection closed signals.

Having to prepare the statement via connection would certainly drive home
its binding to it, but I'm not sure many people think about connections as
transient [happy to be proven wrong here :)]

Further, as an "expert" feature, would it be unreasonable to limit its use
to cases where you know it will benefit, but also only be used in a single
connection?  True, this limits its use cases somewhat, but it's still
available when of benefit.

As to Jeremy's idea of multiple shapes of a single prepared query based on
_potential_ arguments, I disagree.  Much safer [and easier to code] to
detail in the documentation that "because we can't guess at values, you
can't rely on these ORM shortcuts".

Michael:  Perhaps there are more docs you are referencing, but what you
quote there says to me there's little benefit to preparing statements on
MSSQL, not that they actively discourage it.  Certainly, I agree there
should be the ability for PS to behave as a canned QuerySet in cases where
the backend does not support them.  It's safe, easy, and low-surprise.

--
Curtis



On 26 March 2014 06:36, Shai Berger  wrote:

> On IRC, @apollo13 asked some very good questions about the lifecycle of
> prepared statements. I would like to elaborate.
>
> Prepared statements usually live on the server, in the context of a
> session --
> which, for Django, means they're only valid in the thread where they were
> built; without  persistent connections, this would mean "only valid during
> the
> processing of one request", but even with them, connections are sometimes
> dropped. So, prepared statement objects cannot really be long-lived and
> reused
> across requests.
>
> So, I suspect the API:
>
> > ps = MyModel.objects.filter(foo__lt=Param('a')).prepare()
>
> Has good chances to become a mini-footgun -- it all-but tells users
> "prepare
> me once, use me forever", but you really can't do that. It will pass tests
> (run in a single thread over a single connection), and crash in production
> --
> unless a prepared statement can somehow be aware of the connection state,
> and
> take some measures (I don't currently see which) against it.
>
> The main benefit of prepared statements comes when you can prepare them
> once
> then use them many times (with different parameters); but this is very
> atypical
> for Django apps (within a single request). I think if we want this
> feature, we
> should "brand" its API as something for special uses, and give the right
> hints
> about its link to the database session -- so, something like
>
> qset = MyModel.objects.filter(foo__lt=Param('a'))
> ps = connection.prepare(qset)
>
> or maybe even
>
> ps = connection.cursor().prepare(qset)
>
> and also for execution:
>
> results = cursor.execute(ps, a=7)
>
> My 2 cents,
>
> Shai.
>
> --
> 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/201403252136.50615.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_XiSBwBfWSUFdEzLqyc3nOH1WBf%2B6N77VRijbAbLq9TL4i-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Proposal for prepared statements API

[Curtis Maloney]

I've been discussing this idea for some time now, and was reminded of it
recently... and akaariai has pushed me to put forward this proposal.

Prepared Statements.

The benefit of prepared statements, for those who don't know, is it avoids
repeating the time the Query Planner in the DBMS takes to figure out how it
will execute the query.  This can sometimes be quite a significant portion
of the query execution time.

API:

My idea includes two new classes, and one new queryset method.

One class is a handle for a prepared statement, which is a callable
accepting all the bound parameters of the prepared statement.

The other is used for denoting bound parameters in QuerySet construction -
so far we've been calling this Param.

The new QuerySet method would be something like "prepare", which returns a
prepared statement class.

So, a sample of constructing a prepared statement would be:

ps = MyModel.objects.filter(foo__lt=Param('a').prepare()

The result is now a callable that accepts one parameter - "a".  To invoke
the query:

results = ps(a=1000)


Clearly it's early days yet - I've written no code.  And akaariai has
pointed out already there's some corners cases which won't work well with
existing behaviours (e.g. foo=None being silently translated to
foo__isnull=True), but it's best to get this idea under wider public
scrutiny earlier, rather than later.

--
C

-- 
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_XiSCtzeA%2BzcMqLatJi2Vnabbsi2okO_6UXvVExdCEnLKCXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.utils.functional.cached_property

[Curtis Maloney]

On 20 March 2014 08:58, Florian Demmer  wrote:

>
>
> On Thursday, August 8, 2013 6:59:14 PM UTC+2, Łukasz Rekucki wrote:
>>
>> Hi,
>>
>> I have some minor nitpicks:
>>
>> 1. Unlike the standard @property, the current implementation of
>> @cached_property doesn't allow for a docstring.
>> 2. Calling `del obj.` before accessing the value
>> or more then once in a row throws an AttributeError.
>>
>> Should I make a new ticket for that or just send a PR for the old one ?
>>
>>
> wow, that AttributeError is super annoying to handle... i'd apprechiate a
> patch for that if you have it already written!
>

How is it behaving any differently to a normal attribute?

I went through this a year or so ago with RKM - once the property is set,
del will clear it, allowing you to affect the call again.  But if it's
unset, del will raise an AttributeError - just like any other attribute.

--
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_XiSCnEqqgqdrdMmadhc3RAOue2P%2Bv6d4WnK%2B5Eba2Tj7ajA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Curtis Maloney]

For those interested, I've now got my branch working, and only failing
tests related to ensuring no newlines appear inside tags.

You can see the diff here :
https://github.com/funkybob/django/compare/multiline-templates

Now comes the great discovery phase to see how many real-world templates
I've broken, and how much I've altered template parsing performance :)

--
Curtis



On 9 March 2014 20:47, Curtis Maloney <cur...@acommoncreative.com> wrote:

> To try to help the wider community know to contribute comments, I've
> included this thread in the latest Django Update.
>
> My personal stance is -- I know I can add this to the template code
> trivially (See my django-contemplation sandpit).  However, I'm not certain:
>
> a) What performance impact it may have
> b) What potential corner cases in parsing it may expose.
>
> So, unlike all the people just asking for it, I'm going to try it.  :)
>
> A lot of people may not be aware there are _two_ template Lexer/Parser
> pairs in the codebase -- a debug one, and a normal one.  So it's a matter
> of implementing the change in _two_ places.
>
> --
> Curtis
>
>
> On 7 March 2014 07:28, Andre Terra <andrete...@gmail.com> wrote:
>
>> +1, for one simple reason: practicality beats purity.
>>
>>
>> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis <ellis...@gmail.com> wrote:
>>
>>> +1 - I've had the same issue with sorl thumbnail.
>>>
>>>
>>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini <a...@gearspotter.com>wrote:
>>>
>>>> +1 for multiline template tags
>>>>
>>>> Regarding: "we want to discourage putting business logic in the
>>>> template"
>>>>
>>>> Long template tags can happen even if they are logic-less, and they
>>>> would read much nicer over several lines. For example:
>>>>
>>>> {% cloudinary main_image.image width=300 height=300
>>>> class="img-thumbnail main-product-image" crop="fill" gravity="face"
>>>> effect="sepia" %}
>>>>
>>>> There's no business logic here: every parameter in this tag is
>>>> presentational log and belongs in templates (<- unless I'm wrong about
>>>> that, please suggest a refactoring to me if you believe one is appropriate
>>>> here!)
>>>>
>>>>
>>>>
>>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>>
>>>>>
>>>>> On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis <elli...@gmail.com>wrote:
>>>>>
>>>>>> My grandfather was a developer in a nuclear plant that I was
>>>>>> interning at.  They used a Django-based web interface for internal
>>>>>> operations.
>>>>>>
>>>>>> One of the functions their Django application managed was the release
>>>>>> of nuclear material.  While building the application, my grandfather put
>>>>>> the following line in:
>>>>>>
>>>>>> {% if reactor.safe_to_release_deadly_radiation and
>>>>>> reactor.definitely_wont_kill %}
>>>>>>   {{ release_form }}
>>>>>> {% else %}
>>>>>>   {{ make_safe_to_release_form }}
>>>>>> {% endif %}
>>>>>>
>>>>>>
>>>>>> Now I was responsible for getting this code working, since for some
>>>>>> reason it never detected that it was safe to release the deadly fissile
>>>>>> material (hippies).  So I put the following statement in:
>>>>>>
>>>>>> {% if reactor.safe_to_release_deadly_radiation and
>>>>>> reactor.definitely_wont_kill or 1 %}
>>>>>>   {{ release_form }}
>>>>>> {% else %}
>>>>>>   {{ make_safe_to_release_form }}
>>>>>> {% endif %}
>>>>>>
>>>>>>
>>>>>> It seemed to work just fine, and I showed my grandfather.  Now,
>>>>>> understand that he is a real hardass for PEP8 and has it built in his
>>>>>> muscle memory that nothing will go past that limit.  Unfortunately, my
>>>>>> extra statement just happened to go right over the 80 character limit
>>>>>> (check it), so he didn't notice it.
>>>>>>
>>>>>> Fast forward 2 months.  We were looking to release the buildup of
>>>>>> deadly, central nervous system destroying

Re: Revisiting multiline tags

[Curtis Maloney]

To try to help the wider community know to contribute comments, I've
included this thread in the latest Django Update.

My personal stance is -- I know I can add this to the template code
trivially (See my django-contemplation sandpit).  However, I'm not certain:

a) What performance impact it may have
b) What potential corner cases in parsing it may expose.

So, unlike all the people just asking for it, I'm going to try it.  :)

A lot of people may not be aware there are _two_ template Lexer/Parser
pairs in the codebase -- a debug one, and a normal one.  So it's a matter
of implementing the change in _two_ places.

--
Curtis


On 7 March 2014 07:28, Andre Terra  wrote:

> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis  wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is
>>> presentational log and belongs in templates (<- unless I'm wrong about
>>> that, please suggest a refactoring to me if you believe one is appropriate
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>

 On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:

> My grandfather was a developer in a nuclear plant that I was interning
> at.  They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release
> of nuclear material.  While building the application, my grandfather put
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some
> reason it never detected that it was safe to release the deadly fissile
> material (hippies).  So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill or 1 %}
>   {{ release_form }}
> {% else %}
>   {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather.  Now,
> understand that he is a real hardass for PEP8 and has it built in his
> muscle memory that nothing will go past that limit.  Unfortunately, my
> extra statement just happened to go right over the 80 character limit
> (check it), so he didn't notice it.
>
> Fast forward 2 months.  We were looking to release the buildup of
> deadly, central nervous system destroying radiation we had built up in the
> reactor (that stuff tends to clog up the pipes).  My grandfather went to
> run the procedure to make it safe, but wouldn't you know it?  That debug
> statement was still there.  Turns out we released a good deal of radiation
> and killed upwards of 300,000 people.  They had to evacuate the city and
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off
> that he has to scroll past the 80 character column to fix the issue.
>

 As amusing as your story is, hyperbole won't win the argument.

 Hyperbole aside, you haven't added anything to the discussion that we
 didn't already know. Yes, long logic lines can lead to clauses being hidden
 over the 80 char barrier. This isn't news.

 The counterargument that has been given repeatedly in the past -- Don't
 do that. One of the reasons that Django's template logic is intentionally
 hobbled is that we want to discourage putting business logic in the
 template. Not adding multiline tags is one of the contributors to this
 hobbling. Your templates *shouldn't* contain long lines - because if they
 do, You're Doing It Wrong(tm).

 How should it be done? Depending on circumstances, you could refactor
 the "is it ok to show the form" logic into:

  * a method on the reactor object:

 {% if reactor.ok_to_show_form %}

  * the view that constructs the context that the template uses:

 {% if ok_to_show_reactor_form %}

  * a template filter

 {% if reactor|ok_to_show_form %}

  * a template tag 

Re: my admin theme

[Curtis Maloney]

Was just looking at your site... and it looks slick (love admin-tools
Menus), but some of the deps worry me.  BeautifulSoup?

ADMINTOOLS_BOOTSTRAP_SITE_LINK = '/'

Why is this special?  Why doesn't it use staticfiles like everything else?

IMHO the problems with admin go much deeper than the markup/styling... but
I've not had time yet to dig in properly.

--
C


On 4 March 2014 09:35, adam spence  wrote:

> Hi guys,
>
> I was wondering what you thought of my proposal to contribute my bootstrap
> admin theme?
>
> It doesn't make sense to not allow Django admin to be pretty and
> extendable out of the box does it? I do understand however that the admin
> is intended for a developer audience. I am always rapidly prototyping
> systems for clients and the admin always ends up being used by
> non-technical colleagues, which in turn means I (being more of a UI dev)
> get loads of complaints over how hard it is to use once you flesh it out.
> The widgets could do with being easier to re-skin with custom templates
> IMO.
>
> I'd be honoured if you'd let me get this into Django itself. Please let me
> know if you would consider this, otherwise I can just make a module. I'm
> going to rebuild my current django-admintools-bootstrap module and remove
> many of the dependencies.
> https://github.com/spenoir/django-admintools-bootstrap#todo
>
> BTW, I've had quite a few people star it so perhaps the community want it?
>
> all the best,
>
> adam
>
> --
> 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/CAEWLFEH0NA0Mp%3D0uwryNfSfYKYyFkWx8HM16twc5vpRyRJPdZg%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_XiSDB-icT05yMCdsSAfmkvs8oCNbLyrr%2BL6UMcevePs9wog%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

Yah... my oops ... I was reading on my phone and missed the link :)


On 25 February 2014 21:03, Christopher Medrela <chris.medr...@gmail.com>wrote:

> The link is here: http://pastebin.com/DWjE1axV
>
> It times only rendering -- templates are parsed and cached in the setup.
>
>
> On Tuesday, February 25, 2014 8:34:14 AM UTC+1, Curtis Maloney wrote:
>>
>> Did I miss the link to your benchmark code?
>> Does it time just rendering, or parsing also?
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>  --
> 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/eda8c6ea-79b6-4bb1-a4b5-7af8d2dfd3bf%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_XiSBr%2BkokDaX5h27MMEMe2A25PkybfWzBZfO3uTuEe2xuNA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

On February 25, 2014 9:43:49 AM AEDT, Christopher Medrela 
 wrote:
>I've made some benchmarks. The results are:
>
>jinja2 empty for  0.028 s
>jinja2 include1.094 s
>django empty for  0.435 s
>django include2.134 s
>
>Where "empty for" is an empty loop repeated 50 times:
>
>{% for i in range_ %} {% endfor %}
>
>And include is a similar template where the loop body includes another 
>template
>(which is empty) inside for loop:
>
>{% for i in range_ %}{% include "i" %}{% endfor %}
>
>The full code is available here: http://pastebin.com/DWjE1axV
>
>Note that including is only 1.5x faster in Jinja2 compared to Django.
>Surprisingly, the main speedup is in executing for loop (19x), not it's
>
>body.
>
>On Friday, February 21, 2014 11:07:30 PM UTC+1, Kevin Christopher Henry
>
>wrote:
>>
>> Hi Christopher,
>>  
>>
>>>  ... checks the template extension and dispatch to
>>>  corresponding function from `django.dtl` or `jinja2`.
>>>
>>
>> The mechanism for distinguishing the two kinds of template needs to
>be 
>> more flexible. For example, let's say I want to override a
>third-party 
>> template with my own Jinja template. In that case I need to use the
>same 
>> name (.html and all), but I want it to be processed by Jinja. The way
>
>> django-jinja solves this is with a setting that provides a regular 
>> expression to determine which template names get processed by Jinja.
>That 
>> may not be the best way (I can imagine that regular expression
>getting 
>> hairy with a lot of "or" clauses), but just looking at file
>extensions 
>> isn't enough.
>>
>
>Unfortunately, you're right. So I will follow Aymeric Augustin's idea:
>at 
>the
>beginning of every template there will be "{# syntax: django #}" or "{#
>
>syntax:
>jinja2 #}". If the template lacks such declaration, django template is 
>assumed.
>
>I don't have a comment on the merits of your approach to inheriting
>from 
>> DTL templates, but personally this is not something I've ever needed
>to do. 
>> I'm sure there are use cases for this, that's just my experience.
>>
>> By contrast, something that I very often want to do is use
>third-party 
>> Django template tags in my Jinja2 templates. Right now there's just
>no way 
>> to do that (that I know of). So, if you're taking requests, please
>solve 
>> that problem. :-) And if you're forced to prioritize, I think that
>would be 
>> more useful than being able to inherit from DTL templates.
>>
>
>What kind of support do you except for third-party template tags?
>Suppose, 
>that
>`cycle` tag is not builtin. Would it be acceptable to write sth like
>that:
>
>dtl cycle '1' '2' as rows
>
>It could be quite easily implemented as a Jinja2 extensions. Of course,
>I 
>guess
>that you'd prefer this style:
>
>cycle '1' '2' as rows
>
>Unfortunately, it cannot be done easily. Each of template tags should
>map 
>to a
>new Jinja2 extension. But the list of extensions must be given to 
>`Environment`
>constructor and cannot be changed (at least this is what documentation 
>says).
>What can we do?
>
> 1) We can tamper with Jinja2. Maybe it is possible to change list of 
>extensions
>after environment creation? I will investigate it.
>
>2) We need to know all template tags before rendering first template.
>All 
>tags
>  will be available in all templates. The drawback is that you have no 
>modules
>that you can `load` when desired.
>
>BTW, what about built-in template tags? Are there any 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.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-developers/ecf638ce-5811-4234-bd40-964178763090%40googlegroups.com.
>For more options, visit https://groups.google.com/groups/opt_out.

Did I miss the link to your benchmark code?
Does it time just rendering, or parsing also?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/caa369c3-1b9d-461c-9e6c-140eb9d1a941%40email.android.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

I must admit to being conflicted on this project.

I'd love to see the measurements and profiling involved in establishing how
much "faster" Jinja2 is, mostly to see where DTL could do with some love...

However, I don't believe for most people their templates represent enough
of a time cost to make this project worth it.  Certainly, in every project
I'm involved in, it's typically the actual work that takes most of the
time.  Add caching loaders and fragment caching, and, well...

For people where it is, Django already supports pluggable template engines
through Loaders... which also solves the "how to distinguish" problem...

--
Curtis



On 25 February 2014 09:43, Christopher Medrela wrote:

> I've made some benchmarks. The results are:
>
> jinja2 empty for  0.028 s
> jinja2 include1.094 s
> django empty for  0.435 s
> django include2.134 s
>
> Where "empty for" is an empty loop repeated 50 times:
>
> {% for i in range_ %} {% endfor %}
>
> And include is a similar template where the loop body includes another
> template
> (which is empty) inside for loop:
>
> {% for i in range_ %}{% include "i" %}{% endfor %}
>
> The full code is available here: http://pastebin.com/DWjE1axV
>
> Note that including is only 1.5x faster in Jinja2 compared to Django.
> Surprisingly, the main speedup is in executing for loop (19x), not it's
> body.
>
> On Friday, February 21, 2014 11:07:30 PM UTC+1, Kevin Christopher Henry
> wrote:
>>
>> Hi Christopher,
>>
>>
>>>  ... checks the template extension and dispatch to
>>>  corresponding function from `django.dtl` or `jinja2`.
>>>
>>
>> The mechanism for distinguishing the two kinds of template needs to be
>> more flexible. For example, let's say I want to override a third-party
>> template with my own Jinja template. In that case I need to use the same
>> name (.html and all), but I want it to be processed by Jinja. The way
>> django-jinja solves this is with a setting that provides a regular
>> expression to determine which template names get processed by Jinja. That
>> may not be the best way (I can imagine that regular expression getting
>> hairy with a lot of "or" clauses), but just looking at file extensions
>> isn't enough.
>>
>
> Unfortunately, you're right. So I will follow Aymeric Augustin's idea: at
> the
> beginning of every template there will be "{# syntax: django #}" or "{#
> syntax:
> jinja2 #}". If the template lacks such declaration, django template is
> assumed.
>
> I don't have a comment on the merits of your approach to inheriting from
>> DTL templates, but personally this is not something I've ever needed to do.
>> I'm sure there are use cases for this, that's just my experience.
>>
>> By contrast, something that I very often want to do is use third-party
>> Django template tags in my Jinja2 templates. Right now there's just no way
>> to do that (that I know of). So, if you're taking requests, please solve
>> that problem. :-) And if you're forced to prioritize, I think that would be
>> more useful than being able to inherit from DTL templates.
>>
>
> What kind of support do you except for third-party template tags? Suppose,
> that
> `cycle` tag is not builtin. Would it be acceptable to write sth like that:
>
> dtl cycle '1' '2' as rows
>
> It could be quite easily implemented as a Jinja2 extensions. Of course, I
> guess
> that you'd prefer this style:
>
> cycle '1' '2' as rows
>
> Unfortunately, it cannot be done easily. Each of template tags should map
> to a
> new Jinja2 extension. But the list of extensions must be given to
> `Environment`
> constructor and cannot be changed (at least this is what documentation
> says).
> What can we do?
>
>  1) We can tamper with Jinja2. Maybe it is possible to change list of
> extensions
> after environment creation? I will investigate it.
>
>  2) We need to know all template tags before rendering first template. All
> tags
> will be available in all templates. The drawback is that you have no
> modules
> that you can `load` when desired.
>
> BTW, what about built-in template tags? Are there any 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ecf638ce-5811-4234-bd40-964178763090%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 

Re: GSoC 2014 idea proposal

[Curtis Maloney]

I think the most commonly requested feature is how to serilise non-Field
properties of models.

It's easy, but tedious, to do.

Perhaps you could write a mixin to help with this, and improve the
documentation?

However, I don't see this being a task taking more than a few days...

--
Curtis



On 24 February 2014 02:47, Surya K  wrote:

> Hey all,
> Here is the idea (Improving *django.core.serializers* module).
> I have used django serializer module recently and feel its really not that
> beautiful.
>
> 1. Good moderation mechanism in choosing attributes to serialize;
> 2. To sort the order of serialized data
>
> [I am still thinking about what could be done]
>
> That said, I am also seeing different ideas as well. But, looking out for
> an opinion on this one first!
>
> --
> 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/46e6f9ef-9051-4eec-aa61-470f6eeeb10b%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_XiSB5z0Dm%3DGSsA0FpsoTN_Uu3XpxXBiZyU%3DwyR080ZF%2Bm9g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

At this point someone should start asking for real-world examples with
measurements.

I'm personally of the "let's see if we can improve DTL first, then revisit
the question" stance.

But in order to show any improvements, we must have timings for the current
tool.

Can people who've suffered slowness please donate fragments of template
they've found particularly slow?



On 12 February 2014 21:29, Gwildor Sok  wrote:

> There are a few problems with Christian's assumptions:
>
> * Not everyone uses a JS Framework. Personally, we use a lot of static
> pages, and when we do want to do some fancy stuff, we use 
> pjaxto replace content on the page, 
> but in the backend this is still done by
> rendering a full template through a Django view.
>

We run a hybrid side, and fairly high traffic [7k req/min is a fairly
typical] and I've yet to find a major template performance issue that
didn't turn out to be a DB hit hiding in an object, or similar.

That's not to say I don't think it can be faster...


> * The templating language is also used for small stuff, and the switch to
> Jinja would enable using the templating language for even more stuff. The
> biggest issue that comes to mind are template-based 
> widgets
> .
>
> Actually, django-sniplates and django-formulation both allow using another
template as a "bag of macros".  I'm also working on a "just macros" rework
of the idea.  formulation even has a "reuse" tag so you can define template
macros [using blocks] within your template.


> Personally, I'm in favor of switching to Jinja. The speed bonus and the
> ability to call functions with arguments are great features for me.
>

I guess it's time I finally write my "What should I pass in the Context"
blog post... to point out that your designers are [usually] not coders, and
shouldn't have to understand your data structures or schema.  Whilst in
some ways perhaps excessively, DTL does make you consider your data
structures.


> One downside I can think of is that Jinja does not escape variables by
> default, which might become a XSS security issue.
>

That's quite a large downside!

--
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_XiSBmOU%3D4orZnW13bw-ZLT_O416unynhtnQ9%3DhgPtL9Bbtw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

On 11 February 2014 12:31, Luke Sneeringer  wrote:

> On Feb 10, 2014, at 12:16 PM, Carl Meyer  wrote:
>
> It's a problem that we are unable to do things
> that would otherwise be no-brainers (e.g. rendering form widgets using
> templates rather than by concatenating strings of HTML in Python code)
> because our default templating language is too slow.
>
>
> The deliberate hobbling aspect also makes situations like this that should
> be no-brainers into painful slogs. Form widgets are a great example beyond
> this, too, because customizing HTML for particular form elements (e.g.
> adding size="30" to one input field) is an absolute pain. The blessed way
> involves overwriting the field, which requires copying every single
> relevant attribute of the model (and then double-maintaining changes).
>
> The Flask extension's mechanism is {{ field(size=30) }}. Done.
>
> And under this example, it's *DTL* that pushes you to put that logic in
> the wrong place; it doesn't belong in a forms.py file in most places. I've
> even seen cases where the only reason an explicit form *exists* is to
> make small template-level changes.
>
>
>From my own experience [writing formulation] I think it _can_ be easy to
write efficient template-level form rendering, with the right
pre-processing on the form/field objects.  So once again the issue comes
back to "it's not entirely the language, but the objects you pass it."

Just my 2c.

--
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_XiSC7%2B%3Ddnmgzr%3D52%2BQw2rd3gAMUqwGv-DK5cOfhFoEc4faA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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