CacheMiddleware with generation-style caching

[jonathan]

Hi all,

I'm trying to implement a generation-style caching system with django
[1].  I found django-jimmypage [2] which implements an alternative
version of @cache_page, and it uses johnny-cache [3] for an "infinite"
cache timeout.  However, most of the code in django-jimmypage appears
quite similar to what we've got in the default CacheMiddleware, so I'm
trying to implement this without jimmypage by making the following
minor tweaks:

1) Update settings.py to use the johnny backend for infinite-timeout
support and instruct the cache to use a custom key function:

CACHES = {
 'default': {
 'BACKEND': 'johnny.backends.memcached.MemcachedCache',
 'KEY_FUNCTION': 'utils.cache.make_key',
 'TIMEOUT': 0
 }
}

CACHE_GENERATION_KEY = 'generation'

2) Write a custom key function to include the "generation" in the
key:

def make_key(key, key_prefix, version):
 from django.conf import settings
 from django.core.cache.backends.base import default_key_func

if key != settings.CACHE_GENERATION_KEY:
 from django.core.cache import cache
 return default_key_func(key, key_prefix,
 str(cache.get(settings.CACHE_GENERATION_KEY, 1)) + '.' +
str(version))
 else:
 return default_key_func(key, key_prefix, version)

3) Connect to some signals to increment the generation:

def new_cache_generation(sender, **kwargs):
 from django.conf import settings
 from django.core.cache import cache
 try:
 cache.incr(settings.CACHE_GENERATION_KEY)
 except ValueError:
 cache.set(settings.CACHE_GENERATION_KEY, 1)

from django.db.models.signals import post_save, pre_delete
 post_save.connect(new_cache_generation)
 pre_delete.connect(new_cache_generation)

So far, this part works quite well--no crazy hacking of django. :)

However, my trouble is with CACHE_MIDDLEWARE_SECONDS.  From what I can
tell, CACHE_MIDDLEWARE_SECONDS defines *both* the cache timeout *and*
the HTTP headers.  For my purposes, this means that if I set
CACHE_MIDDLEWARE_SECONDS = 0 (meaning I want an infinite cache), then
the HTTP Cache-Control headers include max-age=0 which is not what I
want.  I'd prefer to define the cache timeout via the cache's TIMEOUT
field, and define the Cache-Control via CACHE_MIDDLEWARE_SECONDS.
 'Course, if a view explicitly uses @cache_page() to define a non-
infinite (non-zero) custom timeout, then that timeout should
reasonably impact both the cache timeout and the Cache-Control.

So my question is: does it seem reasonable for me to tweak django to
only use CACHE_MIDDLEWARE_SECONDS for the Cache-Control headers?
Obviously, I can make this change locally, but I'd like to know if I'm
missing something and if this change has any chance of making it
upstream. :)

Thanks!

Jonathan

[1]
http://assets.en.oreilly.com/1/event/27/Accelerate%20your%20Rails%20Site%20with%20Automatic%20Generation-based%20Action%20Caching%20Presentation%201.pdf
[2] https://github.com/yourcelf/django-jimmypage
[3] http://packages.python.org/johnny-cache/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Allow LOGIN_URL to be a callable

[Jonathan Lukens]

+1

This would also be a help in cases where you have different sets of
users and have to use a) to redirect them to the view appropriate to
their account type.

On Oct 14, 6:35 pm, Ulrich Petri  wrote:
> Hi,
>
> in some projects I've had to interface with external authentication
> sources that did expect the return-to URL in other formats than "%
> (LOGIN_URL)s?%(redirect_field_name)s=%(url)s" (In one specific case it
> was, e.g. required that the return URL had to be base64 encoded).
>
> AFAIK there are currently two ways to accomplish that:
>
> a) Set LOGIN_URL to a view that reformats the return URL and redirects
> again (thereby having two redirects in a row)
> b) Monkey patch user_passes_test (formerly _CheckLogin)
>
> Neither of which I think are very good options.
>
> So I would like to propose another option:
> Allowing LOGIN_URL to be a callable which, in case of
> user_passes_test, gets passed the redirect_field_name and return path
> and returns the complete target URL.
> Deciding whether the given string is a callable or an URL should be
> simple; If the string contains at least one '/' it's an URL otherwise
> it's a callable.
>
> If it is felt this would be worthwhile to have in django (or if it is
> even a good idea) I would be happy to provide a patch.
>
> Thanks,
> Ulrich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Thanks for all the hard work

[Jonathan Nelson]

I've been using Django for a bit over a year, and I have to say that I
love it.  It's a beautiful piece of software, and I want to pass on my
gratitude.

Thank you very much for all the hard work that you've put in to
Django.  It makes a big difference to web developers to have a
framework that is so well made, so well thought out and so well
documented.  It's a pleasure working with Django, and I'm looking
forward to working with it for the foreseeable future.

Cheers and best wishes,
Jonathan Nelson

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jonathan S]

Hi Django users,

We made at our company, City Live, a template tag you may be
interested in.
It's a try/catch statement. When anything in the try block fails, a
traceback through all the included templates is shown.

A good approach would be to include {% try %} ... {% endtry %} in the
base template of the whole site, so that any template rendering error
will be caught.

If you prefer a custom message instead of the traceback, the following
is also possible:
{% try %} ... {% except %} custom error message {% endtry %}


Screenshot of the traceback, embedded in our site:
http://github.com/citylive/Django-Template-Tags/blob/master/screenshots/traceback.png

Source:
http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/debug.py

It depends on this {% stylize %} template tag and pygments for the
highlighting.
http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/stylize.py

All feedback is welcome!

Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jonathan S]

On Mar 5, 5:49 pm, Jared Forsyth  wrote:
> I presume these only get shown with DEBUG turned on?

Yes, they are only shown when DEBUG is on:

see line 163:
http://github.com/citylive/Django-Template-Tags/blob/master/templatetags/debug.py#L163


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jonathan S]

On Mar 5, 6:59 pm, Jared Forsyth  wrote:
> On a related note, is there a way to tell templates *not* to fail silently?
> (most tags etc. do)
> for testing/debugging purposes?

I don't think that all template tags fail silently.

Lookup of variables does always fail silently. That is, when a
variable is not found in the context, it will automatically evaluate
to None.  So {{ non_existing_var }} will do nothing, but also {% if
non_existing_var %} ... {% endif %} won't do anything.

{% url name param %}, for instance won't fail silently when reverse
doesn't find a match.
Also, all the template tags that I write for my own use won't fail
silently, because I dislike that behavior.

Probably, if we don't want template tags to fail silently, all we have
to do, is patch the resolve call of variables which is done in most
template tags during the rendering.
Variable('varname').resolve(context)

I will look into this. It should be easy to change that behavior. (and
possibly allow {% try %} ... {% endtry %} catch the variable resolve
error.)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Compilation

[Jonathan S]

Just a few thoughts, this is my idea and I'm not an expert at
compilers, so forgive me if I'm somewhere wrong.

(1) For me, personally, I think the scoping of variables should be
kept inside a block.

{% with "x" as x %}
{% with "y" as x %}
{% endwith %}
  {{ x }}
   - you would print  "y", because you don't pop the context, while
the current template engine would print "x" (no? i didn't test it)
{% endwith %}

(2) Another issue will occur during a rendering error. What if a
template tag throws an exception? The traceback will show the trace
through the generated code, instead of the original templates.

(3) You're code snippets in the examples you are giving are not
equivalent. The second omits at least four print statements, and what
is say in (4) below. So, the timing is not really worth that much.

(4)  How would you compile {{ a.b }} ? I think this can be interpreted
as either a.b(), a[b], or a.b
Python is typed dynamically. So, everytime you want to read out
{{ i }}, this should be changed to:
var_i = i() if callable(i) else i

(5) Be sure that custom template tags, like {% filter escape %} ... {%
endfilter %} still work. A separate result[], to capture the content
of this tag, and apply the filter, is required.

(6) I think that the code generator / compiler you are planning to
write, will be hard to maintain and hard to debug. Because compilers
need to evaluate several ways of how your source code could be written
in the destination language, it should decide which route will mostly
lead to the fasted path at runtime... The dynamic behavior of python
will make it difficult. Compare that to the very clean template.Node
structure, which is understandable for Django developers.


Correct me if I'm somewhere wrong, but I think that the slowness of
the current Django template engine is caused mostly because of the
pushing/popping of contexts and the expensive Variable.resolve. I
think that precompiling the templates to python code and further into
binary, would at most result in 2x the performance.You're proposing to
change the context behavior, are you planning to change the resolve
method also, in order to improve the performance? That and giving up
on the custom template tags, makes me think this is just another,
maybe better, but not really compatible template language.


At the positive side: some things can be improved by the preprocessor.
{% spaceless %} ... {% endspaceless %} can be executed at runtime.


b.t.w. I wrote a compiler for a Python based template language once.
It worked pretty well, also by compiling the template to python
(*.pyc) binary files. (The project is almost dead now, because I
started using Django now for most of my websites.)
http://code.google.com/p/python-pages/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jonathan S]

On Mar 6, 3:36 am, Leo  wrote:
> This is really cool, thanks for sharing it!
>
> One small question though, would it be better to check TEMPLATE_DEBUG
> instead of DEBUG 
> -http://docs.djangoproject.com/en/dev/ref/settings/#template-debug
> ?


Yes, TEMPLATE_DEBUG would be better indeed. Thanks. I'll change that.

Now, I'm also planning to show the locals() for each frame. (Similar
to the original django traceback)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Easier debugging of Django templates. {% try %} ... {% endtry %} template tag and traceback.

[Jonathan S]

> This looks really interesting. Is this something that could be
> integrated into Django's template page itself? It strikes me that this
> sort of feedback would be a good addition to Django's own debug page,
> rather than requiring end users to pepper debug tools like try-catch
> block in their template code.

Hi Russ,

You mean, whether this could replace the traceback from Django without
requiring you to have a {% try %} block in the template?
I'm not 100% sure, but it should be possible to design middleware
which will catch any exception if TEMPLATE_DEBUG and DEBUG are True,
and return this traceback instead.

Certainly something I will take a look at next week.

Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: {% include_partial %} template tag

[Jonathan S]

Something related, that we could really use is passing not just
variables to the include, but also blocks. I tried to implement a
template tag for this, but it doesn't work together with how Django
replaces blocks in the extended template at compile time instead of
during the renderering.

I would like to do:

## in the main template:
...
{% include "decorator.html" %}
   {% block "content" %}
  ...
   {% endblock %}
{% endinclude %}
...

## In decorator.html



{% block content %}{% endblock %}


##
So, the main templates includes decorator.html, but replaces the inner
block "content", by the block it passes to the include.
The decorator pattern, wraps the input in some nodes.

There are use cases where this is required to keep the templates DRY.
I think only a few templating languages are able to do this.
The .NET framework supports the design pattern pretty well, as far as
I remember.

The alternative in this particular example is to use two include tags
"before.html" and "after.html", but is ugly because the opening and
closing html tag are separated over different files.

-- Jonathan


On 8 juin, 19:47, Gregor Müllegger  wrote:
> Also +1 from me for extending the include tag instead of having a new one.
>
> Bye default it should keep its behaviour and use the current context
> for the included template. Marco's use of a new, clean context
> (demonstrated with the snippet below) is also possible to support.
>
>        {% if label %}
>        {{ label }}
>        {% else %}
>
>  You can just pass in an empty string, like one of the following three 
> examples:
>
>     {% include "part.html" with label= title=obj.title %}
>     {% include "part.html" with label="" title=obj.title %}
>     {% include "part.html" with "" as label and obj.title as title %}
>
> (I don't want to propose the implementation of all three syntaxes. I
> just want to demonstrate that all possible syntaxes can handle Marco's
> usecase.)
>
> --
> Servus,
> Gregor Müllegger
>
> 2010/6/8 burc...@gmail.com :
>
>
>
> > I'd suggest to change both include and with/blocktrans syntax into
> > more programmer-friendly style:
>
> > {% include "part.html" title=obj.title|capfirst main_class="large" %}
>
> > This is both more dense, and from quick grasp you can see where are
> > the delimiters ("as" is not so good for this).
>
> > Also I think we need an argument to tell that outer context is passed 
> > inside.
>
> > On Tue, Jun 8, 2010 at 11:30 PM, Gonzalo Saavedra
> >  wrote:
> >> I'm +1 on the optional "with" parameter for {% include %}. -1 on
> >> adding a new tag for this.
>
> >> I also use {% with %}{% include %} a lot in templates but we should
> >> follow with/blocktrans syntax for consistency:
>
> >>  {% include "part.html" with obj.title|capfirst as title and "large"
> >> as main_class %}
>
> >> A related proposal for the "with" tag: It'd be nice to support more
> >> than one variable definition (as blocktrans does):
>
> >>  {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>
> >> The current solution is nesting "with" tags, which is not very pretty.
>
> >> gonz.
>
> >> 2010/6/8 Marco Louro :
> >>> Gabriel,
>
> >>> I only made that decision because I didn't see the need to have whole
> >>> context, and the only time I have needed it was because of the {%
> >>> csrf_token %}. This is just my use-case, but I understand that other
> >>> people might want to use it differently. I don't think it makes much
> >>> of a difference, a clean context may avoid some collisions from time
> >>> to time, but it may have bigger drawbacks for other people.
>
> >>> Hi Jeliuc,
>
> >>> No, I don't.
>
> >>> On Jun 7, 7:59 pm, Gabriel Hurley  wrote:
> >>>> Extending the include tag seems like a fantastic idea! I end up
> >>>> writing the {% with %}{% include %} combo all the time for my reusable
> >>>> template snippets.
>
> >>>> However, I feel like selectively clearing the context inside a
> >>>> template tag is asking for trouble and/or confusion. It also sounds
> >>>> like it goes against Django's "templates require no knowledge of
> >>>> programming" principle. While I can see how you might run into context
> >>>> name collisions in a *very* large or

Re: ANN: multi-auth branch ready for testing

[Jonathan Daugherty]

# Since this stuff is optional I wouldn't be opposed to including
# well- written auth backends to services like OpenID in
# django.contrib.auth... probably worth judging on a case-by-case
# basis.

I know some work on OpenID + Django has already been done, but I'd be
glad to help out with it, as we maintain a large collection of OpenID
implementations, the leader of which is our python library:

  http://www.openidenabled.com/

-- 
  Jonathan Daugherty
  http://www.parsed.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: openid & django

[Jonathan Daugherty]

# I was wondering if anyone else has tried to integrate openID with
# django's user system.
# 
# I was wondering how you store the authenticated URL into the auth  
# system.

I've used OpenID with Django.  I created a table with a user_id FK and
an OpenID URL field.  Each user account mapped to an OpenID had an
empty username and a null password hash, IIRC.  This way, I
authenticate and set the user_id in the session myself, rather than
using Django's auth mechanism.  I wouldn't call this "integration",
though, but it works well.  If you have any best practice or protocol
questions, feel free to hop into #openid on freenode.  I work with the
guys who wrote the original Python implementation.

# does the new multi-auth backend help here? I'm trying to let people
# with openID accounts to sign-in and use my system alongside the
# regular ones.

I haven't used the multi-auth backend so I don't know about that.

-- 
  Jonathan Daugherty
  http://www.janrain.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: openid & django

[Jonathan Daugherty]

# I got it working, and am using the new 1.2 extensions .. which work
# great.

Great!

# http://zyons.com/openid/
# for those who want to try it out.

The openid image doesn't appear in the #id_url element, by the way.
Also, in accordance with the recommendation for OpenID form input
fields, it'd be great if you change the name of the form input field
to "openid_url" so the OpenIDs I (or others) use on other
OpenID-enabled sites will be available as auto-complete choices.
Otherwise, looks great.  Nice handling of the sreg profile data.

-- 
  Jonathan Daugherty
  http://www.janrain.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

#2672 - RSS2.0 feed has no support for copyright element

[Jonathan Buchanan]

Hi all,

Long time listener, first time caller :)

I saw ticket #2672 on the LittleEasyImprovements wiki page today and 
thought it'd be a good opportunity to dip my toes into contributing 
something back to Django. I have a patch for the relevant modules and 
documentation updates ready to go, so before I go any further, I have a 
few questions:

1. Does anyone have any strong opinions on using "copyright" as a 
keyword argument name, given that there's already a "copyright" in the 
builtins? I'm currently using feed_copyright and item_copyright (as Atom 
also supports use of its  element at the item level) for feeds 
and items respectively for this reason.

2. I can't see any existing unit tests for the syndication framework. If 
I submit a patch without including any testing beyond my claims to have 
eyeballed the results of using the framework, will I (or someone else) 
have to write unit tests for the syndication framework before the patch 
goes anywhere? I still wake up in cold sweats thinking about the sheer 
variety of tests defined for Mark Pilgrim's feed parser :)

Thanks,
Jonathan.

--
Jonathan Buchanan
insin.webfactional.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Ticket #2922 - Defining outer joins

[Jonathan Buchanan]

http://code.djangoproject.com/ticket/2922

Could I ask that the functionality proposed in this ticket be
reconsidered for inclusion?

I've encountered a situation where I need to be able to add an outer
join and *also* use the ON clause to specify conditions additional to
the primary key join generated when Q objects are used instead, as was
suggested in the thread [1] linked to with the ticket closing message.

I intended to use QuerySet's 'extra' method to add a 'direction'
property to all retrieved objects which indicated whether the current
user had voted the object up, down, or hadn't voted on the object at
all (to be used when displaying something like Reddit's voting
widgets, but in this case applicable to any model thanks to generic
views). Sample SQL is as follows:

SELECT aa.*, v.direction
FROM anyapp_anymodel aa
LEFT OUTER JOIN votes_vote v
  ON v.object_id = aa.id
  AND v.user_id = 2
  AND v.content_type_id = 15
WHERE aa.id = 1;

Putting the extra conditions in the WHERE clause instead results in a
row not being retrieved at all if the user hasn't voted on the object
it represents.

Thanks,
Jonathan.

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/e071bb8bf57ec0a7

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: The locmem patch and development progress

[Jonathan Daugherty]

# 7. Run the regression tests against every supported version of Python
#with every database backend available.

Do you have a resident buildbot?  That could be used to run the
regression tests on (all pythons) x (all databases).  It would still
take time, of course, but it could at least be automated[1][2].

(How is it done currently, if not with that sort of automation?)

HTH,

[1] http://buildbot.sourceforge.net/
[2] http://www.python.org/dev/buildbot/

-- 
  Jonathan Daugherty
  http://www.b-tree.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Changing django.contrib.auth to make passwords optional

[Jonathan Daugherty]

# Blog post here: http://www.buriy.com/2007/may/12/django-openid-users/
# Download here: http://www.buriy.com/media/openid-solution.zip

For anyone interested, the OpenID 2 release of our python OpenID
library[1] will include a Django app with an example consumer and
server, in addition to the example code previously provided.

[1] http://tinyurl.com/383plw

-- 
  Jonathan Daugherty
  http://www.b-tree.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Claiming Tickets

[Jonathan Wang]

Hi all, 

I was reading up on the documentation for new contributors and was reading 
the "Claiming Tickets" section where it says "If a ticket for this issue 
already exists, make sure nobody else has claimed it. To do this, look at 
the “Owned by” section of the ticket. If it’s assigned to “nobody,” then 
it’s available to be claimed. Otherwise, somebody else may be working on 
this ticket." Is it also safe to claim a ticket that has a blank "Owned by" 
field? If so I figured this could be a quick PR for me to get started with 
updating the documentation.

Thanks for the help!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d50eb87e-6d15-4f90-9df0-c5eda9ff4c63n%40googlegroups.com.

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

[Jonathan Clarke]

Hi all, just wanted to check in to see if a conclusion can be reached on
this idea?  Thanks :)

On Tue, 16 May 2023 at 19:17, charettes  wrote:

> Just wanted to publicly +1 here as well. I was skeptical that we could add
> support for it without invasive changes at first but it seems to be
> relatively straightforward to support.
>
> One ask I would add is that we explicitly document what is support and
> what isn't. For example, at the time `__init_subclass__` is called one
> should not expect `_meta` or any other subclass fields to be available and
> that even when calling `super().__init_subclass__`. That might come as a
> surprise to users that want to do anything to a trivial field addition
> (e.g. perform model introspection). For non-trivial use cases a
> class_prepared signal seems like it's still the best way to run code once
> the class is fully initialized.
>
> Changing these expectations could be done by moving most of the
> ModelBase.__new__ logic to Model.__init_subclass__ but this would require a
> massive re-enginering of meta programming logic that is remain unchanged
> for years.
>
> Le vendredi 12 mai 2023 à 09:38:04 UTC-4, Adam Johnson a écrit :
>
>> +1 from me. As Simon covered on the ticket, the change is small. Making
>> Django classes support __init_subclass__ might unlock some nice dynamic
>> field patterns.
>>
>> On Thu, May 11, 2023 at 12:47 PM hottwaj  wrote:
>>
>>> Hi there, I opened the above ticket and submitted a PR with fix and test
>>> added.  I was asked to bring the issue here for wider review before the
>>> ticket is re-opened (if that is what people agree to do)
>>>
>>> For reference, links to the ticket and PR are:
>>> https://code.djangoproject.com/ticket/34555
>>> https://github.com/django/django/pull/16849
>>>
>>> The issue raised is that current implementation of ModelBase.__new__
>>> prevents use of __init_subclass__ on a Model to add model fields
>>>
>>> e.g. the code listed at the end of this email does not currently work
>>> (the PR fixes this).
>>>
>>> Currently the same result could be achieved by i) writing a new
>>> metaclass e.g. BaseBookModelMeta or ii) using a class decorator where
>>> cls.add_to_class(field) is called.
>>>
>>> Using __init_subclass__ is advised as a simpler alternative to writing a
>>> metaclass to customise class creation, hence this PR.
>>>
>>> Hope that makes sense and appreciate any feedback.  Thanks!
>>>
>>>
>>> class BaseBookModel(models.Model):
>>> class Meta:
>>> abstract = True
>>>
>>> def __init_subclass__(cls, author_cls, **kwargs):
>>> super().__init_subclass__(**kwargs)
>>> cls.author = models.ForeignKey(author_cls,
>>> on_delete=models.CASCADE)
>>>
>>> class Author(models.Model):
>>> name = models.CharField(max_length=256, unique=True)
>>>
>>> class Book(BaseBookModel, author_cls=Author):
>>> pass
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/015a5798-d084-4afb-b800-e83154301ec7n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/El5FRcymxSI/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ffaba0d3-c31d-4e49-bdaf-effb021c149bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFW_ify_bF85Zih%3DHTM4mwE8PYK-8i6keLAn0MgYwuscLmT5Lw%40mail.gmail.com.

Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

[Jonathan Clarke]

Thanks for this and sorry for the delay in coming back.  Good to hear we
can go ahead!

Understood about omitting the changes to _meta and only focussing on the
changes that allow fields to be added via __init_subclass__, i.e. only
making the changes in this PR:
https://github.com/django/django/pull/16849

Can I ask where a good place to document the support of __init_subclass__
would be?
Here are a couple of places I spotted that might be appropriate:
- https://github.com/django/django/blob/main/docs/ref/models/class.txt
- https://github.com/django/django/blob/main/docs/topics/db/models.txt -
perhaps within a new subheading in the Model inheritance section?

Once confirmed I'll amend the PR

Thanks


On Wed, 28 Jun 2023 at 10:28, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> I think we probably won't see much more input, but since Simon and I don't
> have any major concerns we can go ahead. I would also like to see
> documentation about what is supported within __init_subclass__.
>
> The update to make _meta available seems a bit more invasive. The tests
> catch all kinds of corner cases that are hard to deprecate, so if they're
> breaking that may mean the change is not easy or even possible.
>
> On Fri, Jun 9, 2023 at 1:39 PM Jonathan Clarke <
> jonathan.a.cla...@gmail.com> wrote:
>
>> Hi all, just wanted to check in to see if a conclusion can be reached on
>> this idea?  Thanks :)
>>
>> On Tue, 16 May 2023 at 19:17, charettes  wrote:
>>
>>> Just wanted to publicly +1 here as well. I was skeptical that we could
>>> add support for it without invasive changes at first but it seems to be
>>> relatively straightforward to support.
>>>
>>> One ask I would add is that we explicitly document what is support and
>>> what isn't. For example, at the time `__init_subclass__` is called one
>>> should not expect `_meta` or any other subclass fields to be available and
>>> that even when calling `super().__init_subclass__`. That might come as a
>>> surprise to users that want to do anything to a trivial field addition
>>> (e.g. perform model introspection). For non-trivial use cases a
>>> class_prepared signal seems like it's still the best way to run code once
>>> the class is fully initialized.
>>>
>>> Changing these expectations could be done by moving most of the
>>> ModelBase.__new__ logic to Model.__init_subclass__ but this would require a
>>> massive re-enginering of meta programming logic that is remain unchanged
>>> for years.
>>>
>>> Le vendredi 12 mai 2023 à 09:38:04 UTC-4, Adam Johnson a écrit :
>>>
>>>> +1 from me. As Simon covered on the ticket, the change is small. Making
>>>> Django classes support __init_subclass__ might unlock some nice dynamic
>>>> field patterns.
>>>>
>>>> On Thu, May 11, 2023 at 12:47 PM hottwaj  wrote:
>>>>
>>>>> Hi there, I opened the above ticket and submitted a PR with fix and
>>>>> test added.  I was asked to bring the issue here for wider review before
>>>>> the ticket is re-opened (if that is what people agree to do)
>>>>>
>>>>> For reference, links to the ticket and PR are:
>>>>> https://code.djangoproject.com/ticket/34555
>>>>> https://github.com/django/django/pull/16849
>>>>>
>>>>> The issue raised is that current implementation of ModelBase.__new__
>>>>> prevents use of __init_subclass__ on a Model to add model fields
>>>>>
>>>>> e.g. the code listed at the end of this email does not currently work
>>>>> (the PR fixes this).
>>>>>
>>>>> Currently the same result could be achieved by i) writing a new
>>>>> metaclass e.g. BaseBookModelMeta or ii) using a class decorator where
>>>>> cls.add_to_class(field) is called.
>>>>>
>>>>> Using __init_subclass__ is advised as a simpler alternative to writing
>>>>> a metaclass to customise class creation, hence this PR.
>>>>>
>>>>> Hope that makes sense and appreciate any feedback.  Thanks!
>>>>>
>>>>>
>>>>> class BaseBookModel(models.Model):
>>>>> class Meta:
>>>>> abstract = True
>>>>>
>>>>> def __init_subclass__(cls, author_cls, **kwargs):
>>>>> super().__init_subclass__(**kwargs)
>>>>> cls.author = models.ForeignKey(author_cls,
>>>>&

Transactions in the admin

[Jonathan Daugherty]

Hello folks,

I'm interested to know about the status of transaction support in
general, with particular regard to the admin interface and inline
editing.  I see that there was once a short thread started by Kapil,
the submitter of a patch to implement transaction support in ticket
#9.

(Google groups thread link)
http://tinyurl.com/97gge

Are there any plans of further discussion or integration of the patch?
Adrian tells me that this is pending further discussion and a good
implementation.  I'm gearing up to use django for a big project at
work and I'm interested to know where this stands.

Thanks for django!

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Transactions in the admin

[Jonathan Daugherty]

# We should be able to use transactions outside the scope of a Web
# request -- in, say, a Python script or the interactive
# interpreter. Transactions shouldn't be coupled with any other layers
# of the stack.

I agree.  It seems to me that "transaction support" doesn't need to be
anything more complicated than three calls (one to start a transaction
on the django core database connection, one to commit, and one to roll
back).  Is that oversimplification?  Admin code that knows inline
editing is taking place can call BEGIN, COMMIT, and ROLLBACK when
appropriate, but ordinary code runs in "autocommit-style" mode unless
it wants to run something transactionally.  Maybe others have
grandiose plans for transaction support, but again, ISTM that's all we
really need.  The developer gets to choose, and -- paradigmatically
speaking -- it's no different or less powerful than transaction usage
in ordinary web programming.  Does django's persistent connection come
to bear at all on this approach?

On a related but somewhat tangential note, I've noticed that django
creates new database connections periodically (when I use
'runserver'); under what circumstances are new connections opened and
closed?

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Transactions in the admin

[Jonathan Daugherty]

# I think the best way to do commits is to tie them to the request by
# using a middleware that does the commit-rollback-handling. Only
# needed change to django would be a process_exception middleware hook
# that is only triggered if the viewfunc throws an exception - to do
# the automatic rollback. Additionally the middleware would set a
# global flag "don't commit on .save()" that would be adhered to by
# the model code - that way the user can either have the current
# commit-on-.save() functionality or load the transaction control
# middleware to get commit-on-response functionality. Since middleware
# runs for _all_ apps in a project, all apps are handled the same way.

Doesn't this deviate from the standard use of middlewares?  The docs
say, "It's a light, low-level "plugin" system for globally altering
Django's input and/or output."  This sounds like a rather invasive
exception, and it sounds like something that makes this middleware
more than a plugin.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Transactions in the admin

[Jonathan Daugherty]

# So we can't just pass cursors around and let users decide what
# cursor to commit - the commit would have to be on the
# connection. And it would commit all open database changes, even from
# cursors the user didn't really know about.

But *are* cursors being passed around?  I guess I'm assuming that
users will run all of their database interactions through the django
core where things like this can be controlled.  I suppose that users
can go poking around if they want to get cursors or connections, but
IMHO that's a case of too much rope.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Transactions in the admin

[Jonathan Daugherty]

# And middleware already has side-effects like changing elements of
# the request object, for example. Or storing stuff in the cache - the
# caching middleware actually would be a much "bigger" middleware than
# the transaction middleware :-)

Ok, good point.  (But caching still has more to do with the content
itself than does the transactionality of the request.  That's what
inspired the comment.)

# The nice thing about using a middleware for binding transactions to
# the request would be that the transaction stuff won't be coupled
# with the request machinery at all - it's just a middleware the user
# can decide to run or not to run.

But in many cases the transactional nature of the request *is* part of
the request logic, and a simple all-or-nothing wrapper won't do.  I
might want the form-saving aspects of my request to be transactional,
whereas other things, like updating the user's session, etc., would
commit instantly.  You might call those operations "out-of-band" from
the primary task of the request (like inserting an order into the
database), so I think that should be considered in the
implementation.  With your proposal, can you illustrate how one would
accomplish this?

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Transactions in the admin

[Jonathan Daugherty]

# Sure: in those cases you just won't use the "easy-way-out"
# middleware, but just use the "disable-commit-on-save" machinery and
# do explicit commits and rollbacks yourself.

Yeah, that's what I was thinking, but it wasn't yet clear from your
proposal whether it would be easy to toggle between the two.  (As you
say below, code would make all of this easier. :) )

# This discussion is titled "transactions in the admin" - there you
# usually don't have those out-of-band activity, you only have the
# all-or-nothing-approach. The middleware would make stuff like
# transactional admin or simple transactional sites quite easy.

Yeah, true.  I was thinking about mostly non-admin things.

# For more complex sites, just use the decorator_from_middleware to
# create a decorator for transactionality and use that for those view
# functions that should use the all-or-nothing approach and use manual
# transactions in all other cases.

Great; is decorator_from_middleware implemented or still an idea?  I
can't find it mentioned in the docs.

# My idea is just to provide a really easy way to do the
# all-or-nothing approache without taking away the possibility of
# explicit control for those who know exactly what to do. And the
# combined middleware/decorator thingy is working very nicely with the
# caching system, so I just thought it would be the ideal choice for
# the transactionality system, too :-)

Yeah, it sounds like decorators would work very well.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: MS SQL date vs. datetime problem

[Jonathan Daugherty]

# oops
# I put in date and I get datetime back.

But DateTime objects can be used to represent both; you just have a
DateTime object with no time values.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Small report from Django/Rails meetup

[Jonathan Daugherty]

# Why don`t we include Django-Ajax in 1.0? I agree that releasing it
# sooner is good for the project but a nice ajax interface is the
# future for all web applications. Don`t you agree this is an
# imprescindible update?

I think that really goes into the "bells and whistles" category.
Admittedly, AJAX integration of some kind would be nice, but IMHO
there are lots of other bigger, more important things going on that
need to be considered.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Pretty error pages for Django

[Jonathan Daugherty]

# Server error page: http://toys.jacobian.org/django/500.html
# 404 error page: http://toys.jacobian.org/django/404.html

Yay!

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: implicit "pk=" in get_object()?

[Jonathan Daugherty]

# I like it, but I also wish that "__exact" was optional, so I might
# not be a good person to ask...

Interesting idea, although I'd rather all of the conditional kwargs be
consistent, personally.  Making an exception would make it weird.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: implicit "pk=" in get_object()?

[Jonathan Daugherty]

# Actually, Ian's idea was part of my original thinking as well -- if
# you make "__exact" optional, you can completely remove "pk" (which
# is itself a weird exception to the keyword rules).

Yeah, true, although 'pk' is a symbolic substitute for having to
remember what the primary key name is.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Names for Django components

[Jonathan Daugherty]

# 1. Django guitar
# 
# 2. Django beats
# 
# 3. Django singer
# 
# 4. Django piano

Novel, for sure, but wouldn't people have a hard time remembering
which is which?

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Dajngo wishlist

[Jonathan Daugherty]

# Simon, you are saying that FastCGI serves worse than mod_python?

He said "CGI", which is not the same as FastCGI.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Dajngo wishlist

[Jonathan Daugherty]

# I believe that PythonistL did not asked about running it on CGI. He
# asked to run it on the shared webhosting. And noted some issues.

Right: he didn't ask about running it on CGI; it was just stated that
running it on CGI is his only option, and it's such a nasty one that
he ought to consider changing providers.

# I believe that there is / will be shared webhosting with mod_python
# / fastcgi support. (At least he can ask admin of LJW, who posted the
# offer somewhere here :)

Yeah, several providers do exist:

http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts

# 2. mod_python on shared webhosting requires restart of Apache, when django
# models change in order to take effect.
# 3. httpd.conf on shared webhosting is not available (for custom change)
# 
# If we deal with #2 and #3 Django can be more adopted.

I don't see these as restricting adoption, but I don't know the stats
for how many people in shared environments would make use of django.
These things are obviously more a property of the hosting environments
than of how django is designed.  Django already provides a long list
of configuration options to solve this problem.  If one's hosting
provider isn't sufficiently accommodating...

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Data Types

[Jonathan Daugherty]

# This immediately breaks if you extend a field and don't implement
# that method.  Preferably, all the Field classes would implement the
# mapping right there.  Each database shouldn't need to know how to
# map a USState field for example, just strings, dates and integers,
# etc.

But, should each field type know about the various backend types in
order to maintain the mapping?

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Django and AJAX: Setting aside the conflict

[Jonathan Daugherty]

# Sorry for replying to myself.

Don't apologize to us; apologize to yourself!

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Proposal: models.py by default instead of "models" directory

[Jonathan Daugherty]

# * Change Django so that it looks for models in a "models" package
# (as it currently does) *or* in a file called models.py. Either the
# models package or models.py should live directly within the package
# pointed-to by INSTALLED_APPS.

Do you think the extra option will confuse anyone when they're looking
through the docs for the Right Way?  I think the "one way" mantra
applies here..

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Proposal: models.py by default instead of "models" directory

[Jonathan Daugherty]

# But the logic being discussed is the same that Python uses when
# doing imports, so it seems to me to be The Right Way from a language
# POV, no?

Hm.  Yeah.  Supporting a models module would be good for folks who
would like to break their models into different modules, whereas a
single models.py module would make for a cleaner layout if a package
isn't needed.

I was just pointing out that regardless of the pythonic-ness of it, I
wonder if the extra option will confuse newcomers.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Tree structure

[Jonathan Daugherty]

# I'm need to manage catalog of products in my site with multilevel
# structure. How can I'm create model, which can have parents of same
# type as model?..
# 
# something like that:
# 
# class Category(meta.Model):
# 
# name = meta.CharField(maxlength=500)
# parent = meta.ForeignKey(Category)
# 
# def __repr__(self):
# return self.name

Just use:

  parent = meta.ForeignKey("self")

For more information, see:

  http://www.djangoproject.com/documentation/model_api/

(See the "Many-to-one relationships" section.)

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: "Magic" model module change proposal

[Jonathan Daugherty]

# So the goal is to remove these bits of cruft, while maintaining the
# clean separation of "table-level" functions (get_list(),
# get_object()) and "row-level" functions (model methods such as
# save() and delete()).

+1.  Yay!  This was my biggest concern.

# * Models should be in a file models.py, which lives within the app
# package. If you want to split your models over multiple files, just
# import them at the top of models.py.

+1.

# * The automatic module -- which contains the get_object() and
# get_list() functions, along with the automatic manipulators and
# class -- would still be created, but it would live in appname.models
# rather than django.models.  For example, in the polls tutorial, the
# module "choices" in "from django.models.polls import choices" would
# be in myproject.polls.models: "from myproject.polls.models import
# choices".

+1.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: "Magic" model module change proposal

[Jonathan Daugherty]

# Why can't we just allow the model class defined by the user to be
# used?

That doesn't seem promote a clean separation of "table-level"
vs. "row-level" functionality.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: "Magic" model module change proposal

[Jonathan Daugherty]

# Argh. What is the big deal with this? I deleted a screed from my
# original mail about this ridiculously overpumped goal.

That's good. :)

# Just look at the downsides to the magic generated class : wierdo
# issues with visibility, importing, naming, inheritance (quite apart
# from the odd current interpretation of inheritance, things like
# mixins are a nightmare. Georg had something about this somewhere as
# well)

Understood, but these issues don't render the separation of scoped
functionality unimportant.  Have any other ideas?

# There are just so many downsides to having a magic generated class,
# I really can't get excited about seperating class and instance (this
# is an ORM, remember) methods...

If I didn't think combining the functionality in models would confuse
people (particularly newcomers), I could probably agree with you.  But
regardless, I think it's cleaner to keep these functionalities
physically separate.

Maybe the best thing to do would be to round up as many newcomers as
possible and see what they think would be clearer.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: "Magic" model module change proposal

[Jonathan Daugherty]

# Not being funny, but this isn't actually a very good way to design
# anything.
# 
# 'Most' newcomers will design a horrifically bad api if asked, because
# 'most' newcomers have no idea how to design apis.

Maybe I should be more explicit: come up with a list of design
possibilities and ask newcomers which one(s) seem clearer, in terms of
the developement experience.  Obviously asking newcomers to *design*
would not be prudent. :)

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Removing the magic

[Jonathan Daugherty]

# Is there a reason we use a DoesNotExist rather than just
# using a single ObjectDoesNotExist exception for everything?

try:
p = polls.get_object(...)
c = choices.get_object(...)
except ObjectDoesNotExist, e:
...

Which one failed?

Having per-model DoesNotExist exceptions makes it painfully obvious
what sort of error has occurred.  Makes the code that much more
readable, too, IMHO.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Potentially confusing urlconf error messages

[Jonathan Daugherty]

# Not particularly clever, but in a Django request context you could
# argue that "//" == "//" == "/" and change the url pattern logic
# appropriately.

Or just remove all leading slashes from any URLconf entry's regex.

-- 
  Jonathan Daugherty
  http://www.parsed.org

OpenID

[Jonathan Daugherty]

Greetings,

Several weeks ago, I started working at JanRain, Inc., the folks
behind the Python implementation of the OpenID protocol[1].  Of
course, I'd like to push for OpenID integration of some kind into
Django.  It looks like some work has already been done:

  http://badpopcorn.com/2005/12/07/too-many-usernames/

My questions are:

 - Who has already put some thought into this?
 - Who has written code?
 - Should this be done as a middleware?
 - How can I help?

Thanks!

[1] http://www.openid.net
http://www.openidenable.com

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: OpenID

[Jonathan Daugherty]

# http://www.openidenable.com

This should be:

  http://www.openidenabled.com

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: developers needed

[Jonathan Daugherty]

# Hi - after reading the php vs .net vs rails wars I'd like some
# advice on finding shops that primarily do django dvlpmt for start up
# ecommerce sites that can grow comfortably. I've been on google
# search and the freelance sites but I am not getting anyone but php ,
# .net responders.  Any suggestions on how to find a number of
# candidates to consult would be appreciated. A 5-10 K job . thanks

Command Prompt, Inc. does Django and PostgreSQL website development.
You can contact them via the information on their site,

 http://www.commandprompt.com/

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: developers needed

[Jonathan Daugherty]

# I was under the impression that large scaling DB applications are at
# least generally done in mySql

Yeah, this really has to stop. :)

# Is there a consensus that postgre is not the DB of choice for
# ecommerce apps -even if one can here and there point out an
# anecdotal instance?

I'd say the consensus is most certainly the opposite.

Flamingly yours,

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Docutils link in admin interface

[Jonathan Daugherty]

# The admin interface shouldn't be considered the "user" interface --
# it's the interface for trusted content editors.  If you can't trust
# them with implementation details, it should be trivial to create a
# urlconf based on the admin one that leaves out the doc views.

I agree with the trust point you make, but I think his [very valid]
point is that the admin area just doesn't seem like the right place
for the docs to live by default.  I wouldn't expect to find the docs
in the admin area of any application.  I can see how having the docs
in the admin area may be historical and having access to the docs
online *is* really great, but I can't think of a reason why they
should live in admin specifically.

My 0.02 USD,

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Django auth magic

[Jonathan Daugherty]

# I think this would be cleaner if there were an authentication
# utility (just a class probably) that you could switch by changing a
# setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator'

I think it's also worth noting that this won't work if you ever want
to try a sequence of authenticators.  I'm concerned particularly with
OpenID authentication, and OpenID auth is usually tried in addition to
whatever is desired for the site's normal accounts, in which case
authentication mechanisms must be able to coexist.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: Django auth magic

[Jonathan Daugherty]

# If you want to use LDAP or OpenID, you obviously aren't going to use
# a Model for authentication. Especially not a Model which uses a SQL
# schema...

Actually, that all depends on how you want *external* authentication
to affect *internal* accounts.  It may not be enough to say that an
OpenID authentication succeeded; you may need to ask whether that
OpenID maps to a local, actual Django auth *model* record.  (And I
realize that this is version 2.0 of the previous auth discussion, and
that all of this is largely app-specific...)

The auth model needs to be flexible enough to accomodate various
incarnations, such as with LDAP, OpenID, and normal
usernamd-and-password.  So this SQL model's structure does come to
bear heavily on whether we can use other authentication mechanisms
*if* we want external auth to conveniently blend with "normal"
accounts.

-- 
  Jonathan Daugherty
  http://www.parsed.org

Re: How about converting python config files to text config files

[Jonathan Daugherty]

# But automatically installing an app is not a simple thing, the big
# problem is : how to modify the settings.py and urls.py.

I think the answer is writing code in settings.py and urls.py that
looks elsewhere for specific config information, rather than making
settings.py and urls.py text files.  A great deal of Django's
considerable configuration power comes from the fact that these files
are in Python.

I'm -2 on converting these files to anything else, but a HOWTO or wiki
page on "ways to make your settings.py and urls.py files aware of
things that might be site-specific" -- or even a quasi-standard way to
do this sort of thing -- would definitely be good.  I know that in my
projects, I have a PROJECT_HOME environment variable that I define,
for example, which is the directory inside which templates, code, etc
can be found.  It makes deploying production and development copies of
a project very easy.  You can employ similar techniques.

But at any rate, you can always just write a python script that
imports the settings and programmatically traverses them if you need
to inspect them.

-- 
  Jonathan Daugherty
  http://www.parsed.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: How about converting python config files to text config files

[Jonathan Daugherty]

# I have a app name address, now, I want to install it in django. How
# to do that?
# 
# 1. modifying settings.py  to add INSTALLED_APPS
# 2. modifying usrl.py to add urlpatterns
# 3. run install address command

I see what you mean, but this is a one-time task, done at development
time.  I don't think it's bad to do this manually, particularly
because it doesn't need to be done often.  What's the impetus for
wanting an automated way to perform this kind of task?

-- 
  Jonathan Daugherty
  http://www.parsed.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: proposal: endif, endfor etc assume whatever follows in tag is comment

[Jonathan Daugherty]

# It regularly becomes difficult to track which {% endif %} belong to
# which {% if %}, it would be good if we can say {% endif
# start_process %} where start_process is purely comment.

Maybe implement generic support for /* .. */ in template tags?

-- 
  Jonathan Daugherty
  http://www.parsed.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: GSoC 2012 Proposal

[Jonathan Paugh]

On 02/07/2012 02:36 PM, Javier Guerra Giraldez wrote:
> On Tue, Feb 7, 2012 at 2:26 PM, Victor Buldakov
>  wrote:
>>  In my project I would like to develop the support of block with use
>> of the python code.
>>  In my opinion, it would make Django templates more flexible and
>> power.
> 
> from the "Philosophy" section of the template docs:
> 
> "Django template system is not simply Python embedded into HTML. This
> is by design: the template system is meant to express presentation,
> not program logic."
> 
> 
> in other words, the Django designers considered about embedding Python
> and decided against it.
> 
> 
However, there are lot's of other cool things one might do to templates.
Maybe extensions to the syntax would be acceptable, or additional
template tags. (Please note: I'm not a core dev and don't influence such
decisions.)

I believe someone recently suggested incorporating less
(http://lesscss.org/) and bootstrap
(http://twitter.github.com/bootstrap) into Django, and this might be
something you're interested in. At any rate, this list is full of good
propositions.

Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

ticket/15926, advice

[Jonathan Paugh]

Hello.

I just got good-and-into Django, and I'd like to contribute. I worked
some on a patch to ticket #15926
(https://code.djangoproject.com/ticket/15926).

I think this patch deserves some attention. I'd also appreciate some
guidance on contributing, as needed.

I updated the previous patch to a (much) later tip of the git repo, and
expanded it's scope as per my comments on the ticket page. I also added
some documentation for my changes, which I believe is adequate.

Thanks for your help.
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: start using less (and bootstrap!)

[Jonathan Paugh]

There's a big rift here between what people want to do with admin and
what people want to do with django itself. To summarize: the admin
should be amazing by itself and chock full of features, while django
should be empowering without getting in the way.

I've seen a lot of good ideas for admin rejected recently because they
couldn't fit into Django's overall vision. I don't think there is any
way to resolve this rift: it will persist. Django and admin should be
developed separately, likely by separate teams. They could still live in
the same codebase, with an "subofficial" admin fork. Then, the official
django repo could pull in changes according to some suitable policy.

However, maintaining it as a separate project wouldn't hurt, either:
In address to Anssi's concerns: conteaching pip is as easy as `pip
install django-admin`, and the two projects could be tarball-ed together
somehow. (Could it be that hard to teach setup.py to install another
package from a subdir? Or to tar up them separately?) (And what is
virtualenv? Do I need it to install admin? Let's address that in a
separate tutorial, with a link and a notation.)

Peace,
Jonathan

P.S. I'm fairly new here (~1 month), and my perspective is
proportionally skewed.

On 02/03/2012 02:07 PM, Ryan D Hiebert wrote:
> I think that Django's admin app is a killer feature for two main reasons:
> 1. It is automatically installed, and integrated into the tutorial.
> 2. It is used all over in third-party apps, because they can expect it to be 
> there.
> 
> While I appreciate that there may be differences in core vs admin that may 
> slow down development of the admin, I'm wary of removing it from the django 
> install, thinking that it might hurt reason 2, even if it is integrated in 
> the tuturial, and possibly even installed automatically.
> 
> Although as far as the automatic install goes, I'm not sure how that would 
> work. Would it be a dependency? That doesn't make sense.
> 
> On Feb 3, 2012, at 6:21 AM, Max Thayer wrote:
> 
>> The point about admin's appeal to new people is important, but externalizing 
>> it and keeping new people from ever seeing it are very different. Consider: 
>> admin isn't even enabled by default. You have to follow the tutorial on how 
>> to enable it. If admin weren't included in Django proper, we could just 
>> change the tutorial to "Apps are awesome; here's how to download and install 
>> one written by someone else." New users could meet pip sooner, and otherwise 
>> understand how to integrate with the broader python/django community's 
>> various creations.
>>
>> Actually, a friend of mine and I have been plotting out externalizing 
>> various parts of contrib, like admin and auth. Are any groups currently 
>> pursuing those goals as well?
>>
>> Best regards,
>> Max
>>
>> On Fri, Feb 3, 2012 at 8:35 AM, Brendan Smith 
>>  wrote:
>> I give +1 to the idea of separating out the admin and letting people fork 
>> and modify to their hearts content
>>
>> I also still give my +1 to having it utilize less, but I am also cautious 
>> like others about prescribing bootstrap specifically , especially the JS 
>> since as others have pointed out is somewhat unstable right now and not very 
>> easy to use at times (took me a long time to figure out modals)
>>
>> Sent from my iPhone
>>
>> On Feb 3, 2012, at 1:25 AM, Harris Lapiroff  wrote:
>>
>>> The Django admin is a major—if not *the* major—selling point to
>>> budding developers. I worry that externalizing it (hence making it a
>>> *separate* piece of software that needs to be discovered and
>>> installed, which seems simple but can be quite a challenge to new
>>> coders) might take away Django's non-expert appeal. When I started
>>> using Django, I knew no python. The only reason I was able to make
>>> that work was because of the Django admin. If the admin gets kicked
>>> out, I think it should be made *very* obvious where to find one.
>>>
>>> I'd be wary of putting them in core but I think using Bootstrap and
>>> Less for a new admin (whether internal or external) would make its
>>> development much faster. Dependencies should not be a problem. I think
>>> jQuery is a pretty apt analogy here. You probably won't write much
>>> javascript for the Django admin without learning jQuery. You can if
>>> you want to. But most people don't need or want to write javascript
>>> for the Django admin anyway. I think a framework like Bootstrap it
>>> would actually simplify adding new featu

Re: auth.User usernames

[Jonathan Slenders]

On 16 fév, 13:05, Tom Evans  wrote:
> 75 isn't large enough these days for either email or username. We run
> a patched version of django for some time that has changed both these
> fields to 255 characters in order to accommodate the needs of our
> users. See RFC 3696.

This and other issues made us moving away from contrib.auth and
contrib.sessions. It's not too hard to write your own custom
authentication and session middleware, and you can migrate whereever
you want to. The main problem is if you depend on other libraries with
rely on the existance of auth.models.User, like contrib.admin.

Personally, I think a lot of the apps in django.contrib have a lack of
flexibility. Maybe it's good to leave these apps as they are, but
start something like contrib_v2, as the improved version.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Jonathan French]

Since we're consensus building or whatever the fancy term is, another +1.

Mainly for comments, since {# #} is far, far more readable than {% comment
%}{% endcomment %} even with syntax highlighting, but also for other tags
too, particularly long i18n ones -- or even relatively short ones where you
have complex nested HTML and have indented yourself against a wall, but are
coding to a style which insists on a hard right margin, no exceptions.

Soft word wrapping isn't the best option, since you can produce a much
clearer result through manual line breaks and alignment than your editor
can through wrapping at the last word on the line.

This is a tiny change which would make many people's lives easier. I'm very
surprised at Django, with the whole "batteries included" thing,
deliberately withholding a feature for aesthetic reasons. When did you turn
into GNOME? ;-) Please reconsider.

- ojno

On 24 February 2012 10:29, Ivan Kharlamov  wrote:

> On 02/24/2012 01:29 PM, Chris Northwood wrote:
> > A +1 from me too, I've really felt the pain on this when doing i18n
> > templates, I understand the aesthetics, but the aesthetics of
> > obscenely long tags is also bad imo...
> >
> > On 24 February 2012 09:23, Shawn Milochik  wrote:
> >> On Fri, Feb 24, 2012 at 4:19 AM, Bradley Ayers 
> wrote:
> >>>
> >>> In the interest of making the wider community opinion heard, I too am
> +1 on this, my feeling is exactly the same as Stephen.
> >>>
> >>> --
> >>
> >> +1
> >>
> >> I understand that a BDFL has spoken and this change isn't going to
> >> happen. I hate to add to the noise, but since the argument from
> >> popularity fallacy has been invoked, I feel the need to point out that
> >> many of us didn't bother to weigh in because we didn't choose to add
> >> to the noise. Especially after the case was so well-made by others --
> >> it didn't seem necessary.
> >>
> >> Shawn
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> >> To post to this group, send email to django-developers@googlegroups.com
> .
> >> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >>
> >
>
> +1
>
> If you are against truly multiline tags, consider supporting a line
> continuation character sequence (something like backslash in most of the
> programming languages) inside tags, which a poor template author can use
> as a last resort to make his code readable.
>
> In the docs, discourage people from going multiline. Highlight that it
> is the last thing to do (like PEP does).
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Newline stripping in templates: the dnl way

[Jonathan French]

Jinja implements whitespace control by putting a minus sign after/before
the % in a tag - http://jinja.pocoo.org/docs/templates/#whitespace-control -
I haven't tried it myself, but it looks like {% tag -%} is equivalent to
your {% tag %}{# .

On 24 February 2012 17:37, Tobia  wrote:

> Tai Lee wrote:
> > I don't think adding {# to the end of lines is easy to understand at a
> > glance, it doesn't even convey a hint of meaning like "dnl" does
>
> I beg to differ.  {# is already recognized by template authors as
> meaning "start of comment", and they know (or should know) that it
> cannot extend through more than one line.  Therefore I'd think it
> intuitive that it will "eat" till the end of the line and not beyond.
>
> Look:
>
> Here are your subscriptions:
> {% for thing in things %}{#
>  - {{ thing.name }}
>   You added it on {{ thing.date }}
> {% endfor %}{#
> you can manage your subscriptions...
>
> Tom Evans wrote:
> > I'd be strongly -1 on anything that makes template language look more
> > like m4!
>
> I'll tell you, m4 can be quite addictive once you grasp the basics! :)
>
> > This could be addressed by having a different open/close tag for tags
> > which chomp the preceeding/next character if it is a newline. Eg:
> > {^ for item in folder ^}
>
> I don't think adding new reserved characters would make the language
> simpler for template authors, nor for the the template parser, nor for
> the sake of backwards compatibility.  {# is already part of it.
>
> But I can see the need to chomp whitespace before a template tag, as
> well as the newline after it.
>
> Martin J. Laubach wrote:
> > For this (avoiding newlines) the currently discussed multiline tags
> > would work pretty well too without adding more cruft to the template
> >language:
> >
> > foo bar {#
> > #}baz
>
> If this can be accomplished without massive performance penalties, I
> agree with you.
>
> Maybe {# #} could be made multiline at first, with special code, while
> waiting for a proper implementation of generic multiline tags.  This
> would certainly be more forward-compatible than my proposal above
> and it would solve more whitespace problems, if not all.
>
> Tobia
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Revisiting multiline tags

[Jonathan French]

On 24 February 2012 17:16, Alex Gaynor  wrote:

>
>
> On Fri, Feb 24, 2012 at 12:06 PM, h3  wrote:
>
>> > If you'd like to make an argument as to *why* it's useful, that's
>> useful, but we don't take polls.
>>
>> I think the argument as to why it's useful as been made quite
>> extensively.
>>
>> On the flip side, beside the ivory tower philosophical stance, I did
>> not see much
>> compelling argument as to *why* this is a bad idea.
>>
>>
> Django is nothing other than ivory tower philosophies (and I really hate
> this "ivory tower" insult, as if it's a bad thing to be principled and
> philosophically sound) applied to APIs.  If it violates the philosophy, it
> shouldn't go into an API.
>
>
>> If you think it makes your templates look ugly, well just don't use
>> it. You'd still have the choice.
>>
>>
> No.  If it's an API, it doesn't need to be used by me in order to poison
> my experience with Django.
>

*How* does it "poison your experience"? Just the knowledge that someone,
somewhere isn't writing code to your linebreak style?


>
>> Meanwhile some other people think it would make their templates more
>> readable, but
>> unfortunately they don't have the luxury to choose because an
>> architect think it's ugly.
>>
>> At this point I think it's worth mentioning that it's a not a beauty
>> contest. And even if it was,
>> I don't see the beauty in lines of code that are 10 feet long.
>>
>>
> In another thread someone had an example of a multi-line tag, and I
> actually commented to my computer on how ugly I found it. Beauty may be in
> the eyes of the beholder, but the reason we have BDFLs is to keep those
> decisions consistent.  Glyph Lefkowitz's keynote from DjangoCon this year
> really drives this home.
>

What is the no-linebreak behaviour consistent with?


>
>
>>
>> On Feb 24, 10:15 am, Daniel Moisset  wrote:
>> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor 
>> wrote:
>> >
>> > > Folks, you seem to have missed Russell's point.  Even if 100 people
>> +1 this,
>> > > it's meaningless.  That's a tiny fraction of this mailing list's
>> readership,
>> > > much less of the Django community at large.  Django is the way it is
>> > > because, first and foremost, of taste.  If you'd like to make an
>> argument as
>> > > to *why* it's useful, that's useful, but we don't take polls.
>> >
>> > It's useful because it helps some templaets in some cases be more
>> readable
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Newline stripping in templates: the dnl way

[Jonathan French]

Let me make sure I've got this right --- The situation being discussed is
not where whitespace is insignificant and can be stripped, but where
whitespace is important and you want to control the exact amount of it,
e.g. plain text emails. In this case, just using stripwhitespace is not
enough. Right?

On 25 February 2012 04:27, Tai Lee  wrote:

> What's better about {% for x in y -%} or {^ for x in y ^} over {%
> stripwhitespace on %} at the top of your template, followed by {% for
> x in y %}? I think the latter is far more readable.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: make the File Storage API works with a file-like object instead of the Django File object.

[Jonathan French]

You can create a Django file object from any file-like object just by
passing it to the constructor.

django.core.files.File(my_file_like_object)

This is basically what all the storage backends do where there is an
existing file object from whatever source, and what you have to do if you
want to save an existing file to a FileField.

- ojno

On 28 February 2012 22:28, Michael  wrote:

> Hi,
>
> The File Storage API only works with the Django File object (https://
> docs.djangoproject.com/en/1.3/ref/files/storage/ ;
> https://docs.djangoproject.com/en/1.3/ref/files/file/).
> Wouldn't it be a good idea to make a Django file-like object instead
> and make the Storage API works with it ?
> That way we could use the current Django File object when it is real
> files but also use a "remote" file object like the urllib2.urlopen
> returns.
>
> What do you think ?
>
> Best,
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Jonathan French]

That's true, but I agree it seems a useful enough hook to make it a hook,
rather than needing to do it yourself like that. I would vote for it being
called 'preprocess', to make it clear that it's both optional and run
before the method-specific function.

- ojno

On 2 March 2012 13:40, Michael van Tellingen
wrote:

> Hi,
>
> This should already be quite easy to implement, do something like:
>
>def dispatch(self, *args, **kwargs):
># Some code
>return super(YourView, self).dispatch(*args, **kwargs)
>
> Regards,
> Michael
>
>
> On Fri, Mar 2, 2012 at 11:58, Charlie "meshy" Denton
>  wrote:
> > I would like to see something like this too. I my suggestion is
> > here: https://gist.github.com/1957251
> >
> > This method has two advantages:
> > 1. You can modify the request, args, and kwargs before they get saved to
> the
> > view.
> > 2. You can execute code after request, args, and kwargs are saved but
> before
> > the dispatch handler is called.
> > 3. You can save extra variables to self as required
> >
> > I expect 2 is probably the most common use case.
> >
> > Meshy.
> >
> >
> >
> > On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote:
> >>
> >> Hi all,
> >>
> >> Apologies if this has been raised before. I've had a look around and
> can't
> >> find a good way of doing this with the current code.
> >>
> >> I regularly have views which rely on some custom code which runs some
> >> sanity checking on the request and is independent of method. As an
> example,
> >> consider a view which creates an object related to a parent. This is
> easily
> >> achievable by overriding the form_valid method of CreateView and
> excluding
> >> the foreign key from the form. However, the view should return a 404 if
> the
> >> related object specified by the url does not exist. Written as a non
> class
> >> based view, the natural flow is to try to load the parent object from
> the
> >> database, handle it as necessary, and then split paths depending on
> whether
> >> we have a get or post. It is currently very difficult to emulate this
> >> without duplication of some sort.
> >>
> >> My proposal is that we add a process_request (or similar name) method
> >> which is called by the dispatch method immediately before the method
> handler
> >> is called. (i.e. here). This would then allow pre-processing and sanity
> >> checking of the request object, using the args, kwargs and request that
> have
> >> been saved on the class, before delegating off the the respective
> views. The
> >> method should return None or an HttpResponse subclass. If it returns
> >> something, then we return that directly from the dispatch method.
> >>
> >>
> >> I can supply some code (my proposal is pretty simple I think) but I
> >> thought I'd open it up for discussion first.
> >>
> >> Marc Tamlyn
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/django-developers/-/z63TmT57twQJ.
> >
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Jonathan French]

That's not the case - get_context_data, get_queryset, are examples of hooks
like this preprocess one, not places where more would be added. I'm not
sure if there's a better analogy.

Overriding the dispatch method would be the correct solution if you wanted
to behave the same towards all methods, but seems a bit heavy for factoring
out validation or common code between methods where you still want your
get/post/etc to be called (or not, as the case may be.)

- ojno

On 2 March 2012 15:22, Andre Terra  wrote:

> Then that would also be the case for many other methods in generic
> class-based views, like get_context_data, get_queryset, etc.. I hate
> boilerplate code as much as the next guy, but I'm not sure I follow why
> this single method would get a special hook. Correct me if I'm wrong, but
> special cases aren't special enough to break the rules.
>
>
> Cheers,
> AT
>
>
> On Fri, Mar 2, 2012 at 11:53 AM, Jonathan French 
> wrote:
>
>> That's true, but I agree it seems a useful enough hook to make it a hook,
>> rather than needing to do it yourself like that. I would vote for it being
>> called 'preprocess', to make it clear that it's both optional and run
>> before the method-specific function.
>>
>> - ojno
>>
>>
>> On 2 March 2012 13:40, Michael van Tellingen <
>> michaelvantellin...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> This should already be quite easy to implement, do something like:
>>>
>>>def dispatch(self, *args, **kwargs):
>>># Some code
>>>return super(YourView, self).dispatch(*args, **kwargs)
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> On Fri, Mar 2, 2012 at 11:58, Charlie "meshy" Denton
>>>  wrote:
>>> > I would like to see something like this too. I my suggestion is
>>> > here: https://gist.github.com/1957251
>>> >
>>> > This method has two advantages:
>>> > 1. You can modify the request, args, and kwargs before they get saved
>>> to the
>>> > view.
>>> > 2. You can execute code after request, args, and kwargs are saved but
>>> before
>>> > the dispatch handler is called.
>>> > 3. You can save extra variables to self as required
>>> >
>>> > I expect 2 is probably the most common use case.
>>> >
>>> > Meshy.
>>> >
>>> >
>>> >
>>> > On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> Apologies if this has been raised before. I've had a look around and
>>> can't
>>> >> find a good way of doing this with the current code.
>>> >>
>>> >> I regularly have views which rely on some custom code which runs some
>>> >> sanity checking on the request and is independent of method. As an
>>> example,
>>> >> consider a view which creates an object related to a parent. This is
>>> easily
>>> >> achievable by overriding the form_valid method of CreateView and
>>> excluding
>>> >> the foreign key from the form. However, the view should return a 404
>>> if the
>>> >> related object specified by the url does not exist. Written as a non
>>> class
>>> >> based view, the natural flow is to try to load the parent object from
>>> the
>>> >> database, handle it as necessary, and then split paths depending on
>>> whether
>>> >> we have a get or post. It is currently very difficult to emulate this
>>> >> without duplication of some sort.
>>> >>
>>> >> My proposal is that we add a process_request (or similar name) method
>>> >> which is called by the dispatch method immediately before the method
>>> handler
>>> >> is called. (i.e. here). This would then allow pre-processing and
>>> sanity
>>> >> checking of the request object, using the args, kwargs and request
>>> that have
>>> >> been saved on the class, before delegating off the the respective
>>> views. The
>>> >> method should return None or an HttpResponse subclass. If it returns
>>> >> something, then we return that directly from the dispatch method.
>>> >>
>>> >>
>>> >> I can supply some code (my proposal is pretty simple I think) but I
>>> >> thought I'

Re: [GSoC 2012] Schema Alteration API proposal

[Jonathan French]

On 18 March 2012 23:33, Russell Keith-Magee  wrote:

> > 2. An inspection tool that generates the appropriate python code after
> >inspecting models and current state of database.
>
> The current consensus is that this shouldn't be Django's domain -- at
> least, not in the first instance. It might be appropriate to expose an API
> to extract the current model state in a Pythonic form, but a fully-fledged,
> user accessible "tool".


Is there a writeup anywhere of why this is the consensus? AFAICT it looks
like Django already provides half of this in the form of
DatabaseIntrospection, that e.g. South actually uses, which generates a
model class from the current state of the database. Doing the diff as well
doesn't seem like much of a stretch, and might make it more likely for
third party custom fields to be made migrateable, if the interface for
doing so is in Django core.

- ojno

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: suggestion: Don't make the tag "url" dirty in Django1.5

[Jonathan French]

That example is incorrect.

{% url app_views.client %}

will not change to

{% "url app_views.client" %}

it will change to

{% url "app_views.client" %}

which, as you can see, enables passing the view from something other than a
literal string.

On 27 March 2012 09:22, gs412  wrote:

> In Django1.5
>
> {% url app_views.client %}
>
> will change to
>
>> {% "url app_views.client" %}
>
>
> I think it is a stupid idea
> Why so many people use django? becouse of 'DRY', but now django become
> more and more 'dirty'
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/-kXfyDKv3-MJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Model inheritance extended.

[Jonathan Slenders]

Hi everyone,

This may be interesting to some of you. I created a small library for 
inheritance of *a set of* models.
It's best to go quickly through the Readme on the site below.

We felt a need for this, but I'm wondering whether some kind of inheritance 
like this has been discussed before. And whether, if useful, this would 
make a candidate for django.db.

https://github.com/citylive/django-model-blueprint

Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WIkRQuzDRCsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Automatic deployment tool

[Jonathan Slenders]

Hi Everyone,

In the past there have been some discussionh about how to deploy Django web 
applications through SSH. How to use Fabric or other tools, and whether we 
should provide or maybe force users to deploy applications according to a 
certain conventions.

Back then, maybe already more than a year ago, I said that I was working on 
my own deployment tool. [1] Something that could be used instead of Fabric. 
It's a tool which could probably help a lot of you, although it can take a 
while to adopt. The core consists of high quality code. I took me a while 
before I felt confident enough for releasing this, and it has been 
refactored more then any project I did before. Things still can be 
improved, but it's ready to share with you.

Key features are:

   - Interactive execution of remote commands. Locally, they will appear in 
   a pseudo terminal (created with openpty), so that even editors like Vim or 
   Emacs works fine when you run them on the remote end. You can easy start an 
   interactive shell on any host as well.
   - Reusability of all deployment code is a key point. It's as declarative 
   as possible, but without loosing Python's power to express everything as 
   dynamic as you'd like to. Deployment code is hierarchically structured, 
   with inheritance where possible.
   - Parallel execution is easy when enabled, while keeping interaction 
   with these remote processes possible through pseudoterminals. Every 
   parallel task gets his own terminal, either a new xterm or gnome-terminal 
   window, a tmux pane, or whatever you'd like to.
   - Logging of your deployments. New loggers are easily pluggable into the 
   system.


So, enjoy!

So, what does it have to do with Django? I have a setup-definition of what 
we use for Django deployment [2]. However, I suppose that quite a lot of 
people aren't using uwsgi like us. So, I'd like to know what the most 
common use cases of Django deployment are. If I can cover most cases, it's 
very easy for end-users to pick one, override what they don't like, and 
enjoy the full power of this deployment system.

For instance, to demonstrate the power. If we want to connect to a Django 
shell_plus of our Mobile Vikings production system, we type in the 
interactive shell:

> mobile_vikings django shell_plus

This will call the shell_plus function of our django setup, it will ask on 
which host the shell needs to be started, and immediately fire an 
interactive shell_plus of the remote server in your terminal.

[1] https://github.com/jonathanslenders/python-deployer
[2] 
https://github.com/citylive/citylive-operations/blob/master/deployment/deployer/contrib/services/django.py

I'll publish one of these days on pypi.

All feedback is welcome. For bugs/feature requests on things which arn't 
Django related, please go to the github.

Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/k4RS_9Kmn9cJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Automatic deployment tool

[Jonathan Slenders]

Thanks for your feedback, Cal,

You're right about the documentation, some very useful parts aren't even 
documented at all. (There are comments in the code, but there are some 
little things you wouldn't know from the readme.)

During the last years I also put most of the effort in experimenting and 
getting something really useful. It took a while before I got there, and it 
didn't make sense to document features which were to be refactored every 
now and then. However, now I feel its quite stable. I should start making 
better documentation, and a lot of usage examples. I also cannot deny that 
the learning curve may be a little bit steeper then Fabric in the very 
beginning, but soon you will see the advantages. If only I were as good in 
selling a project as I can code. :)

Anyway, I hope this can also improve automatic deployment of Django 
applications for other people.

Cheers,
Jonathan


Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media 
Ltd] a écrit :
>
> Hi Jonathan,
>
> Just from a very brief point of view.. my eyes started to glaze over 
> whilst looking at the github README, and even more so when I looked at the 
> code.
>
> Even if this was the best thing since sliced bread, the documentation in 
> its current state leaves me with the feeling of "why do I want to use this".
>
> I think what would benefit this project massively is good/easy to read 
> documentation, with a simple overview section explaining common uses, what 
> makes it better than alternatives, etc.. maybe via readthedocs..?
>
> Statements such as "It's as declarative as possible.." sound impressive, 
> but don't really give me much insight into what this is, and why I'd want 
> to use it.
>
> Hope this helps!
>
> Cal
>
> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders 
> 
> > wrote:
>
>> Hi Everyone,
>>
>> In the past there have been some discussionh about how to deploy Django 
>> web applications through SSH. How to use Fabric or other tools, and whether 
>> we should provide or maybe force users to deploy applications according to 
>> a certain conventions.
>>
>> Back then, maybe already more than a year ago, I said that I was working 
>> on my own deployment tool. [1] Something that could be used instead of 
>> Fabric. It's a tool which could probably help a lot of you, although it can 
>> take a while to adopt. The core consists of high quality code. I took me a 
>> while before I felt confident enough for releasing this, and it has been 
>> refactored more then any project I did before. Things still can be 
>> improved, but it's ready to share with you.
>>
>> Key features are:
>>
>>- Interactive execution of remote commands. Locally, they will appear 
>>in a pseudo terminal (created with openpty), so that even editors like 
>> Vim 
>>or Emacs works fine when you run them on the remote end. You can easy 
>> start 
>>an interactive shell on any host as well. 
>>- Reusability of all deployment code is a key point. It's as 
>>declarative as possible, but without loosing Python's power to express 
>>everything as dynamic as you'd like to. Deployment code is hierarchically 
>>structured, with inheritance where possible. 
>>- Parallel execution is easy when enabled, while keeping interaction 
>>with these remote processes possible through pseudoterminals. Every 
>>parallel task gets his own terminal, either a new xterm or gnome-terminal 
>>window, a tmux pane, or whatever you'd like to. 
>>- Logging of your deployments. New loggers are easily pluggable into 
>>the system.
>>
>>
>> So, enjoy!
>>
>> So, what does it have to do with Django? I have a setup-definition of 
>> what we use for Django deployment [2]. However, I suppose that quite a lot 
>> of people aren't using uwsgi like us. So, I'd like to know what the most 
>> common use cases of Django deployment are. If I can cover most cases, it's 
>> very easy for end-users to pick one, override what they don't like, and 
>> enjoy the full power of this deployment system.
>>
>> For instance, to demonstrate the power. If we want to connect to a Django 
>> shell_plus of our Mobile Vikings production system, we type in the 
>> interactive shell:
>>
>> > mobile_vikings django shell_plus
>>
>> This will call the shell_plus function of our django setup, it will ask 
>> on which host the shell needs to be started, and immediately fire an 
>> interactive shell_plus of the remote server in your termina

TIMEZONE default

[Jonathan Loy]

Hey everybody,

Quick question. In version 1.6 why is TIME_ZONE in 
django.conf.global_settings<https://github.com/django/django/blob/master/django/conf/global_settings.py>
 set 
to 'America/Chicago', but in the default project template TIME_ZONE = 
'UTC'? Shouldn't they be the same, and if so which one? Thanks for taking 
the time to read/answer my queston.


v/r
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: TIMEZONE default

[Jonathan Loy]

Thank you Alex and Aymeric for your responses. Since that is the situation, 
maybe an explanation should be included in the settings documentation? 

On Saturday, February 9, 2013 5:51:51 PM UTC-5, Aymeric Augustin wrote:
>
> Alex' answer is correct — and "later on" is actually a few days ago :)
>
> UTC isn't a best practice as much as a country-agnostic practice. You're 
> supposed to put your own time zone there.
>
> There are a few other discrepancies between global_settings.py and the 
> default project template, notably USE_L10N and USE_TZ.
>
> If you search the archives of this mailing list you'll find a detailed 
> explanation for USE_TZ.
>
> -- 
> Aymeric.
>
>
> Le 9 févr. 2013 à 23:44, Alex Ogier > a 
> écrit :
>
> Hi Jonathan,
>
> I don't know the particular history of this setting, but this sounds like 
> something that was done to maintain backwards compatibility. My guess is 
> that when Django was first released, it defaulted to 'America/Chicago' but 
> later on it was recognized that using UTC time on the server is a better 
> way of handling times. As a result, if the settings module doesn't contain 
> a TIME_ZONE setting, then you get 'America/Chicago' in order to be 
> backwards compatible, but when you make a new project you get the current 
> best-practice setting which is UTC.
>
> Best,
> Alex Ogier
>
>
> On Sat, Feb 9, 2013 at 12:21 PM, Jonathan Loy 
> > wrote:
>
>> Hey everybody,
>>
>> Quick question. In version 1.6 why is TIME_ZONE in 
>> django.conf.global_settings<https://github.com/django/django/blob/master/django/conf/global_settings.py>
>>  set 
>> to 'America/Chicago', but in the default project template TIME_ZONE = 
>> 'UTC'? Shouldn't they be the same, and if so which one? Thanks for taking 
>> the time to read/answer my queston.
>>
>>
>> v/r
>> Jonathan
>>
>> -- 
>> 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?hl=en.
>> 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-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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
> -- 
> Aymeric.
>
>
>  
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Jonathan Slenders]

Le mardi 5 mars 2013 20:35:07 UTC+1, Michael Manfre a écrit :
>
> Full disclosure, I maintain django-mssql and am biased toward having all 
> database backends treated as if they were 3rd party backends.
>

The question is, how monolithic do we want to have Django?

If we would move database backends out of core. Why not move everything in 
django.db away from core? There are other ORMs for Django. And the same is 
true for the templating system.

For me, personally, it's really a big +1 for splitting Django up in several 
logical parts, and for removing the global state. (So that we could create 
a Django *instance*, and add a postgres *instance* to django ourself.)

I want to to see something like this:

d = Django(
database_backend=Postgres(postgres_settings),
urls=our_url_patters,
templates=TemplateSystem(template_settings),
midldeware=...,
   )

No disadvantages I think. But it's not an easy migration path.

Cheers,
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: javascript view for named urls

[Jonathan Slenders]

As Andrew says, some "rely" on the obscurity of this server side 
information. The same can be said of translations. I'd like to see better 
support for javascript preprocessing.

gettext(...) in javascript could be preprocessed if the language is known.
url_resolve('name', { ...}) could probably also be precomputed, if you're 
smart.

When projects evolve, translation files and url patterns can become large, 
and you don't always want to simply expose all of them.

I'm not sure whether there's already a recommended way for adding compile 
hooks to collectstatic. In debug mode, a fallback to some catalog could be 
a solution.



Le samedi 30 mars 2013 17:24:36 UTC+1, Bernhard Ja a écrit :
>
> Am Freitag, 29. März 2013 21:05:05 UTC+1 schrieb Andrew Ingram:
>
>>
>> I like the concept of this, because it's something I've often wanted 
>> myself. But I want to bring up a couple of points: 
>>
>> 1) Some websites rely on the obscurity of some of their URLs as an 
>> additional security measure (i.e. have the admin at something other than 
>> /admin/). This is admittedly not a great measure, since a persistent 
>> attackers will probably get around it. But the key would be a way to manage 
>> which patterns get included in the javascript catalog, possibly even having 
>> it configurable at the the view level so that some templates can request a 
>> different subset of the patterns to others. 
>>
>
> I agree. A way to manage the existenz in the js catalog is necessary.
>  
>
>> 2) It'd be nice if it could be integrated with internationalisation, so 
>> that if you're using Django's i18n_patterns, the view automatically fills 
>> in the country segment based on the request's locale. Much like the 
>> translation string view only returns the strings for the request's 
>> language. 
>>
>
>  I did some tests and the language code prefix appears in the generated 
> urls. Am i missing sth.?
>
> Whats the best was to propose this feature for the django core? 
>
> Bye, Boerni
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: websockets

[Jonathan Slenders]

Maybe it's worth noting that Guido is working on a Tulip, a specification 
for an asynchronous API in Python 3, this to get some consensus. Right now, 
there is almost zero compatibility between al the different approaches: 
twisted, tornado, gevent, etc...

If we decide to go for one technology, better be future proof.

Gevent has some issues. It's doing fine most of the time, but the monkey 
patch approach could really break some stuff.
I like something like Twisted's wsgi container and callfromthread. However, 
I think Twisted it way to hard for the average Django user. It's not really 
intuitive, but hopefully, Tulip will provide us with a nicer API.


Le mardi 16 avril 2013 21:25:08 UTC+2, Jacob Kaplan-Moss a écrit :
>
> Hi Ashwin - 
>
> On Tue, Apr 16, 2013 at 2:10 PM, Ashwin Kumar 
> > 
> wrote: 
> > is there any way to implement websockets in django? 
> >  if not, any other packages to combine with django. 
>
> There are quite a few third-party apps and demos out there, so many 
> I've lost track. I recommending searching GitHub. 
>
> >  is there any future plan to implement it in django core? 
>
> I hope so; it was a topic of much discussion at DjangoCon. In the last 
> year, there've been a couple of demos put together by core developers: 
>
> * https://github.com/ptone/django-live 
> * https://github.com/aaugustin/django-c10k-demo/ 
>
> So I think I could sum up the current state as this: 
>
> * Most of us would like to see some sort of real-time support in Django. 
> * There's proof that it's possible technically. 
> * But there's little-to-no consensus on what form this would take, or 
> how to implement it. 
>
> It's probably going to take some time and a great deal of effort to 
> come together on that last point. In the meantime, like I said there 
> are a ton of different apps, demos, and utilities out there, so you 
> should be able to put together a "real-time" app without too many 
> issues. But for something more holistic... it could take a while. 
>
> Jacob 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Nested blocks in base template.

[Jonathan Slenders]

Hi all,

Somebody reported a bug for django-template-preprocessor. I'm wondering 
whether this is documented behaviour for the Django template language, or 
whether this is just something that happens to be this way because of the 
implementation.

https://github.com/citylive/django-template-preprocessor/issues/24


in base:

some html here{% block base %}{% block one %}block 
one{% endblock %}{% endblock %}


In inherited:

{% extends "template_base.html" %}a little bit more html here{% block 
base %}{{ block.super }}and more html{% endblock 
%}{% block one %}overriden block{% endblock %}


The result of Django:

some html hereoverriden blockand more html



Is this documented? If so, then I need to fix it.
(btw, django-template-preprocessor deserves an update as well. It's still 
working nice, but hasn't seen that much progress last year.)


Thanks,
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Automatic deployment tool

[Jonathan Slenders]

Hi all,

Some improvements have been made and documentation is coming.

For the curious, here is a 5min screen recording of me using it on our 
deployment environment that I'll present this weekend on djangocon-europe. 
You can watch it here:

https://vimeo.com/66302371


It shows:

- The hierarchical architecture of the deployment tree. (navigation through 
the nodes.)
- Interacting with remote redis shell and the django shell. (some of our 
deployment services.)
- source code introspection
- sandboxing of deployments.
- one complete (sandboxed) setup of our distributed application.

What's not shown, but great:
- typing "--connect" will open a bash shell on the remote end of the 
current node.
- introspection of everything
- a lot more.


Feedback is very welcome, but maybe keep it off django-developers.

https://github.com/jonathanslenders/python-deployer/

Enjoy!
Jonathan


Le lundi 10 décembre 2012 01:07:21 UTC+1, Cal Leeming [Simplicity Media 
Ltd] a écrit :
>
>
>
> On Sun, Dec 9, 2012 at 11:40 PM, Jonathan Slenders 
> 
> > wrote:
>
>> Thanks for your feedback, Cal,
>>
>> You're right about the documentation, some very useful parts aren't even 
>> documented at all. (There are comments in the code, but there are some 
>> little things you wouldn't know from the readme.)
>>
>> During the last years I also put most of the effort in experimenting and 
>> getting something really useful. It took a while before I got there, and it 
>> didn't make sense to document features which were to be refactored every 
>> now and then. However, now I feel its quite stable. I should start making 
>> better documentation, and a lot of usage examples. I also cannot deny that 
>> the learning curve may be a little bit steeper then Fabric in the very 
>> beginning, but soon you will see the advantages. 
>>
>  
>
>> If only I were as good in selling a project as I can code. :)
>>
>
> I know that feeling
>  
>
>>
>> Anyway, I hope this can also improve automatic deployment of Django 
>> applications for other people.
>>
>> Cheers,
>> Jonathan
>>
>>
>> Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media 
>> Ltd] a écrit :
>>>
>>> Hi Jonathan,
>>>
>>> Just from a very brief point of view.. my eyes started to glaze over 
>>> whilst looking at the github README, and even more so when I looked at the 
>>> code.
>>>
>>> Even if this was the best thing since sliced bread, the documentation in 
>>> its current state leaves me with the feeling of "why do I want to use this".
>>>
>>> I think what would benefit this project massively is good/easy to read 
>>> documentation, with a simple overview section explaining common uses, what 
>>> makes it better than alternatives, etc.. maybe via readthedocs..?
>>>
>>> Statements such as "It's as declarative as possible.." sound impressive, 
>>> but don't really give me much insight into what this is, and why I'd want 
>>> to use it.
>>>
>>>  Hope this helps!
>>>
>>> Cal
>>>
>>> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders >> > wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> In the past there have been some discussionh about how to deploy Django 
>>>> web applications through SSH. How to use Fabric or other tools, and 
>>>> whether 
>>>> we should provide or maybe force users to deploy applications according to 
>>>> a certain conventions.
>>>>
>>>> Back then, maybe already more than a year ago, I said that I was 
>>>> working on my own deployment tool. [1] Something that could be used 
>>>> instead 
>>>> of Fabric. It's a tool which could probably help a lot of you, although it 
>>>> can take a while to adopt. The core consists of high quality code. I took 
>>>> me a while before I felt confident enough for releasing this, and it has 
>>>> been refactored more then any project I did before. Things still can be 
>>>> improved, but it's ready to share with you.
>>>>
>>>> Key features are:
>>>>
>>>>- Interactive execution of remote commands. Locally, they will 
>>>>appear in a pseudo terminal (created with openpty), so that even 
>>>> editors 
>>>>like Vim or Emacs works fine when you run them on the remote end. You 
>>>> can 
>>>>easy start an interactive she

Template preprocessing (to improve template rendering speed, en page filesize)

[Jonathan S]

Hi all,

At my current job, I spent a week of programming on a preprocessor for
Django templates.
In short, what it does is compiling the templates in a more compact
version, dropping all useless information and preprocessing
templatetags where possible. The Apache benchmark tools showed a page
load improvement up to twice as fast in Django 1.2, and 4 times as
fast in the older Django version and HTML pages are now only half as
big in filesize now.

It is completely transparent, there are no changes needed to the
templates, and should only be installed as a template loader (wrapping
around the original loaders).

What is does, in the Django language is:
* preprocess {% trans %} and {% blocktrans %} when they don't take
variables parameters. (the template loader will have a 'cache' for
each language)
* preprocess inheritance. Combining parent and child templates by
replacing the blocks, and filling in {{block.super}}. {% block %} tags
can be removed because all inheritance has been determined. (Note,
this doesn't work with {% extends variable_name %}, but I think it's a
bad idea to have variable inheritance. (but can be disabled if you
would need it.)
* preprocess {% include "path" %}, if path is not a variable.
* grouping {% load statements %}
* resolve all {% url %} when they don't take variable parameters.
* preprocess {% now "Y" %}  (we will restart our server at least once,
after a year transition. :p )
* We have a few tags, like {% google_analytics %}, which constantly
output the same code, this is implemented as a custom preprocessor
extension for ourself.

Now, if the template is HTML, we do a little more optimizations:
* Remove all whitespace between block-level HTML tags
* Removing empty class attributes, like class="", (which may appear as
a result of class="{% block name %}{% endblock %}", where the child
template din't implement the block.)
* Merge all 

i18n bug in template rendering.

[Jonathan S]

I guess, we found a bug, not sure if it has been reported earlier and
whether this is the right place to report.

When a template contains translations in variables, like
{{ _("text") }}, the text seems to be translated already during the
creation of the Template object. Every following call of
Template.render() will output the translation which was made earlier.
(Possibly in the wrong language.)

Templates are cached in 'django.template.loaders.cached.Loader', so
this bug makes constructions like  {{ _("text")|upper }} impossible.


=Test code: =

from django.utils import translation
from django.template import Template, Context


def language(language_code):
class with_block(object):
def __enter__(self):
self._old_language = translation.get_language()
translation.activate(language_code)
def __exit__(self, *args):
translation.activate(self._old_language)
return
with_block()


with language('en'): # Output 'Yes'
 Template("{{ _('Yes') }}").render(Context({}))


with language('fr'): # Output 'Oui'
 Template("{{ _('Yes') }}").render(Context({}))


with language('nl'): # Output 'Ja'
 Template("{{ _('Yes') }}").render(Context({}))


with language('nl'): # create template, while environment language is
dutch
t = Template("{{ _('Yes') }}")

with language('fr'): # Render in French -> output is still Dutch
('Ja')
t.render(Context({}))


= Output =

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.utils import translation
>>> from django.template import Template, Context
>>>
>>>
>>> def language(language_code):
... class with_block(object):
... def __enter__(self):
... self._old_language = translation.get_language()
... translation.activate(language_code)
... def __exit__(self, *args):
... translation.activate(self._old_language)
... return
with_block()
...
>>>
>>> with language('en'): # Output 'Yes'
...  Template("{{ _('Yes') }}").render(Context({}))
...
u'Yes'
>>>
>>> with language('fr'): # Output 'Oui'
...  Template("{{ _('Yes') }}").render(Context({}))
...
u'Oui'
>>>
>>> with language('nl'): # Output 'Ja'
...  Template("{{ _('Yes') }}").render(Context({}))
...
u'Ja'
>>>
>>> with language('nl'): # create template, while environment language is dutch
... t = Template("{{ _('Yes') }}")
...
>>> with language('fr'): # Render in French -> output is still Dutch ('Ja')
... t.render(Context({}))
...
u'Ja'

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: i18n bug in template rendering.

[Jonathan S]

See also: http://pastebin.com/Wstya2C6

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: i18n bug in template rendering.

[Jonathan S]

> You aren't supposed to use _('Foo') as a standalone variable.
> (see last paragraph 
> herehttp://docs.djangoproject.com/en/1.2/topics/i18n/internationalization...)


Why shouldn't I use it as a standalone variable? (A language should
have a *context free* grammar, which means, that the underscore
function can be used in any variable. But that's no problem in
Django.)


That's not the point, the bug applies to any variable, template tag or
template filter parameter. It seems like a bug to me:
Any underscore function is translated during the initialisation of the
template, and that is wrong to me.

I guess, also for this one, like mentioned in the documentation.
{% some_special_tag _("Page not found") value|yesno:_("yes,no") %}

And I did a quick test:


with language('nl'):
 t = Template("{% load i18n %}{{ 1|yesno:_('yes,no') }}")

t.render(Context()) # Will output 'ja'
with language('en'):
  t.render(Context()) # Will still output 'ja', even if the language
is English now...



The underscore, which is a parameter for a template filter, is also
translated during the initialisation of the template...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: i18n bug in template rendering.

[Jonathan S]

Thanks Ramiro, we hope the patch will be applied in the next release.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal for inclusion of two additional default template tags.

[Jonathan S]

Hi all,

Like {% include %} and {% extends %}, I think we can include two more
template tags in Django's defaulttags for controlling the "render
flow". Click the links below for a usage example.


** A {% macro %} template tag
http://paste.pocoo.org/show/316592/

** And a {% decorate %} template tag:
http://paste.pocoo.org/show/316593/


I think they are generic enough to be included.
{% decorate %} implements a commonly used design pattern. (Also known
by XAML programmers.) It avoids the need of having to split a template
into a head.html and footer.html, which is a bad practice, because it
separates matching opening and closing tags over two files.

{% macro %} avoids the usage of external template files. I think it's
not worth the overhead of using an external file, when someone has to
repeat small parts of code in a template. And further, it's more clear
when the macro code is defined on top of the file where it's used.

The linked code samples have been used for several months now, without
any problems. (And at our office, we can't anymore live without.)

I hope for some feedback about what you think of including this in
defaulttags and wether you'd like to see something different.

- Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for inclusion of two additional default template tags.

[Jonathan S]

Not really. But I believe it's still pretty fast using Django's render
engine. Probably about the same speed as using {% extends %} or {%
include %}


(By the way. We are working on a template preprocessor as well, and
every {% extends %}, {% include %}, {% macro %} and {% decorate %} is
preprocessed. So we can offer a new, smaller template to Django's
render engine without any of these tags. Rendering gets pretty fast ;)
We forbid here to use variables for template includes or inheritance,
so there's no reason to decide inheritance at run time.)


On 7 jan, 17:23, "Jonas H."  wrote:
> On 01/07/2011 05:11 PM, Jonathan S wrote:
>
> > ** And a {% decorate %} template tag:
> >http://paste.pocoo.org/show/316593/
>
> +1
>
> > {% macro %} avoids the usage of external template files. I think it's
> > not worth the overhead of using an external file, when someone has to
> > repeat small parts of code in a template.
>
> +1, but did you actually do some benchmarking on this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for inclusion of two additional default template tags.

[Jonathan S]

> Regarding the macro-tag I think the idea is valid but I'd personally
> prefer a more flexible approach regarding variables being  provided
> for the macro block. Something like Jinja's macro comes to mind where
> I can define parameters for each macro and then pass them in as needed

Jinja's approach does not work with the Django templates.
- The whitespace in the template tags does not work well.
- Calling the macro method as a Variable instead of using a template
tag can probably not be done without rewriting compile_filter
(variable resolving from context) from scratch. I'm not sure about
this.

I think passing variables to includes has been discussed before, and
if we implement the {% macro %} tag, it should be done in a consistent
way.

Currently, you would do:

{% with "var" as variable %}
  {% callmacro "macro_name" %}
{% endwith %}

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Missing semi-colon

[Jonathan S]

Hi Django admin developers,

Can you please insert a semi-colon in the following file, behind line
90?

django/contrib/admin/templates/admin/edit_inline/tabular.html


var updateSelectFilter = function() {
// If any SelectFilter widgets are a part of the new form,
// instantiate a new SelectFilter instance for it.
if (typeof SelectFilter != "undefined"){
$(".selectfilter").each(function(index, value){
  var namearr = value.name.split('-');
  SelectFilter.init(value.id,
namearr[namearr.length-1], false, "{% admin_media_prefix %}");
})
--> please insert semi-colon here.
$(".selectfilterstacked").each(function(index, value){
  var namearr = value.name.split('-');
  SelectFilter.init(value.id,
namearr[namearr.length-1], true, "{% admin_media_prefix %}");
})
}
}

Thanks a lot,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Missing semi-colon

[Jonathan S]

Aparently, there are several semicolons missing at several places:

django/contrib/admin/templates/admin/edit_inline/tabular.html  lines
90, 94 and 124
django/contrib/admin/templates/admin/edit_inline/stacked.html  lines
45, 48 and 78

Of course, this really is a minor issue, but easy enough to fix.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Missing semi-colon

[Jonathan S]

Thanks, I made a patch and created a ticket.

http://code.djangoproject.com/ticket/15490


On 23 fév, 13:48, Russell Keith-Magee  wrote:
> On Wed, Feb 23, 2011 at 8:24 PM, Jonathan S  
> wrote:
> > Aparently, there are several semicolons missing at several places:
>
> > django/contrib/admin/templates/admin/edit_inline/tabular.html  lines
> > 90, 94 and 124
> > django/contrib/admin/templates/admin/edit_inline/stacked.html  lines
> > 45, 48 and 78
>
> > Of course, this really is a minor issue, but easy enough to fix.
>
> Thanks for the report -- the best (and preferred) way to report this
> is to open a ticket in Trac, ideally with a patch describing the
> change you think needs to be made.
>
> Yours,
> Russ Magee %-)
>
>
>
>
>
>
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Bug in ManyRelatedManager.get_query_set?

[Jonathan S]

Hi,

Some question about the current behavior in the ManyRelatedManager in
django.db.models.fields.related.

This manager has a method get_query_set. Why is it that the model name
of the field where the foreign key is defined in, is passed to the
database router? I think it's more logical to pass the model where the
foreign key points to instead.

Suppose we have a Model1 and Model2. And Model1 defines a foreign key
to Model2. We have an instance model1. So, the property
model1.model2_id exists. Now we retreive the model2 object by doing:
"model1.model2". This will cause a query Model2.objects.get(id=...) to
be executed. Model1 is defenitely not involved, so I think there's no
reasen to pass Model1 to the router, instead of Model2.

This patch should solve it:
http://paste.pocoo.org/show/343888/


cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Compilation

[Jonathan S]

Hi all,

I have also been working for about a year on such a template compiler,
and recently published it on Github. You may be interested in this
project:

https://github.com/citylive/django-template-preprocessor


** Short summary of what already is possible, and what still needs to
be done:

The template preprocessor consists of two parts.
-1-
A compiler which compiles the template in a compact version, (removing
comments, preprocessing l18n for all enabled languages, preprocessing
inheritance, includes, etc..., compressing HTML, CSS and javascript,
and combining external CSS/JS references.)
The output is a single template directory, which is still compatible
with the Django template render engine, but should render about twice
as fast.
-2-
A second compiler which takes the already manipulated parse tree of
-1-, and compiles it further into Python code. The output is a
directory of .py files for all templates. This part is still
experimental, and not extensively developed because it completely
bypasses Django's render engine and template parser at runtime. I had
the problem that it is incompatible with all custom template tags. So,
they need to be rewritten. I got rendering speeds of about 20 times as
fast as Django's own render engine.

So, what does it does at compile-time:
(a)
- remove django comments
- preprocess i18n tags as long as they don't contain variables.
- preprocess URLs when they don't contain variables.
- preprocess MEDIA_URL, SITE_DOMAIN and other static variables
- preprocess inheritance. (one important incompatibility: {% extend
"..." %} should only get a string as parameter, not a variable! But
honestly, I really don't know why someone would do that.
- preprocess {% include tags %}
- don't output any {% block %} tags, because they are meaningless now.
- group all {% load %} statements
(b) if this is a HTML template:
- parse the HTML tree. (the lexer will parse HTML in a 'django parse
tree')
- validation of HTML (note that we don't need to render any template
for validating html)
- merge internal CSS files
- compress HTML (remove whitespace)
- remove HTML comments
- parse the CSS/javascript.
- remove CSS and javascript comments.
- compress css
- compress javascript. (remove whitespace and shorten variable names.)


Basically, we all get these optizations at compile time. A very simpel
template loader will load the compiled template which renders much
faster by django's engine, because it has been optimized and is much
smaller now. This part is really stable.

The second compiler -2-, is able to take the output, and compile it
even further into python code, taking as much advantage as possible of
the Python interpreter.
It does also variable renaming like replacing:
{% with x as long_variable %}
with
{% with x as y %}
choosing the first free variable which has not yet been used inside
the inner scope.
This has been proven to work, but not yet recommended.


Let me know if you have other questions. There is more I have to tell,
but I'm a little busy right now...
Have a nice day,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Compilation

[Jonathan S]

Maybe. We solved that use-case by adding another custom directory to
TEMPLATE_DIRS when we had to override the base template. But I can
imagine that someone wants to be able to dynamically change the base
template, from inside a view or context processor.

This was a choice we made, because almost all the other features
depend on this. Having dynamic inheritance means having {% block %}
tags processed during rendering, and it means not being able to
process any of the HTML/css/js at compile time. For now, I have no
intension to change this behaviour, but of course anyone is welcome to
contribute.

Somehow, I'm still not really convinced of dynamic inheritance. It
feels like doing this in Python:

class A(random.choice([list,dict])): pass



On 28 mar, 18:13, Jacob Kaplan-Moss  wrote:
> On Mon, Mar 28, 2011 at 11:04 AM, Dan Fairs  wrote:
> > We don't have a core site base template. Each client on our system gets
> > their own, as IA/branding etc. varies considerably (and indeed includes
> > chunks of markup that the client supplies directly).
>
> ... and congratulations, you've successfully reversed-engineered the
> very use-case that led us to create this feature in the first place!
>
> Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for Template Engine Refactoring

[Jonathan S]

+1 on this.

Are you planning on keeping the API for registering template tags
compatible?  (django.template.Library.register.tag)
I think this may be required for backwards-compatibility, but
personally, I'd like to see a cleaner API for this, which doesn't
expose the parser details. (Writing template tags should not involve
any token manipulation.)


On 29 mar, 13:55, Armin Ronacher  wrote:
> Great. Google groups decided to reflow my mail. Here in actually
> readable version:http://paste.pocoo.org/show/362024/
>
> Regards,
> Armin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Template Compilation rev.2

[Jonathan Slenders]

> Alex Gaynor wrote:
>
>     ... The
>     semantics of Python code is that variables assigned in a for loop
>     exist beyond the loop itself, including the looping variable. Django
>     templates, however, pop the top layer from the context stack at the
>     end of a for loop. This intermediate representation uses the scoping
>     of  Django templates.

You should map the context altering template tags to Python scopes,
like

from:
{% with a as b %} ... {{ b }} {% endwith %}

to:

def __(b):
  print b
__(a)

this may be a little overhead, but I think it's the best way to
overcome the side-effects of assignments.



> Alex Gaynor's example
> ~
> .. sourcecode:: html+django
>     {% for i in my_list %}
>         {% if i|divisibleby:2 == 0 %}
>             {{ i }}
>         {% endif %}
>     {% endfor %}
> .. sourcecode:: python
>     def templ(context, divisibleby=divisibleby):
>         my_list = context.get("my_list")
>         _loop_len = len(my_list)
>         result = []
>         for forloop, i in enumerate(my_list):
>             forloop = {
>                 "counter0": forloop,
>                 "counter": forloop+1,
>                 "revcounter": _loop_len - i,
>                 "revcounter0": _loop_len - i - 1,
>                 "first": i == 0,
>                 "last": (i == _loop_len - 1),
>             }
>             if divisibleby(i, 2) == 0:
>                 result.append(force_unicode(i))
>         return "".join(result)

In the perfect world, you would be able to know at compile-time which
variables are used in the inner scope. (Custome template tags don't
report which context variables they access. Imho, they should only be
able to access variables which have been passed as template tag
parameters, but they often access 'request.user'  and other variables
without asking.)
In this example, you know for sure that the {{ forloop }} variable has
not been used, so there's no need to build this object.

>     def templ(context, divisibleby=divisibleby):
>         my_list = context.get("my_list")
>         _loop_len = len(my_list)
>         result = []
>         for i in my_list:
>             if i % 2 == 0:
>                 result.append(i)
>         return "".join(map(force_unicode, result))

I translated the devisibleby filter by "i % 2 == 0". This should be
possible. Allow template filters to be implemented as a built-in which
renders python code. Doing this for all the core template tags may
significantly improve speed. My implementation of the divisibleby
filter is: [1]

> @register_native_template_filter('divisibleby')
> def divisibleby(generator, subject, arg):
> """ {{ var|divisibleby:3 }} """
>return '(%s %% %s == 0)' % (subject, generator.convert_variable(arg))

[1] 
https://github.com/citylive/django-template-preprocessor/blob/master/src/template_preprocessor/render_engine/render.py#L1388

Further, don't forget to support the {% filter %} tag scenario. I
don't know whether using a 'result' variable is the best way. But if
it is, you could turn a filter tag into the following code and nest in
your other generated code. So, it'll override 'result' in the inner
scope.

> def _f():
>result = []
>...
>return my_filter''.join(result))
> result.append(_f())

Isn't context.my_list faster than context.get("my_list")  ?




It's interesting to see someone else taking the challange of writing a
template-to-python compiler. :)
Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation

[Jonathan Slenders]

How exactly do you want to solve dynamic inheritance? It seems that
some people are still interested in dynamic inheritance, by using {%
extends variable %}. (Which is still dirty in my opinion, but anyway.)
Block information has to be kept somehow.


Maybe one small improvement. Isn't the following
  > date(context.variable or "Default value"),"Y-m-d")
faster than this?
  > date(default(resolve(context,variable),"Default value"),"Y-m-d")


P.S. I like the cleanness of adding an (optional?) compile method to
every Node-derived class.
But on the other hand, I would like to see Django move to a more end-
user-friendly way of defining custom template tags. A way which does
not involve any knowledge of the template parser/interpreter/compiler.
Of course, that could also be build upon the first.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation

[Jonathan Slenders]

Hi Andrey

I haven't yet looked through all of your code, but already a little
feedback.

Remember that every dot operator requires a dictionary lookup or
getattr call. Also the [ ]-operator is another level of redirection. I
think using 'self' inside a for-loop is not a good idea. If you're
going to compile, you really want to optimize every possible detail.


On Mar 31, 6:00 pm, Andrey Zubko  wrote:
> ...
>     def super(self,key):
>         if len(self._levels) > 1 :
>             for level in xrange(1,len(self._levels)) :
>                 if self._levels[level].has_key(key) :
>                     return self._levels[level][key]
>         else :
>             if self._levels[0].has_key(key) :
>                 return self._levels[key]   ###  You mean:  return 
> self._levels[0][key]
>             else :
>                 return ""


Maybe turn it into this:

>     def super(self,key):
> levels = self._levels
>         if len(levels) > 1 :
> iter = levels.__iter__()
> iter.next() # Ignore first item
> for level in iter:
>                 if level.has_key(key) :
>                     return level[key]
>         else :
>             return levels[0].get(key, "")


Now you have only one lookup in 'self', half the amount of index
operators (has_key counts as index operator), no additional xrange
iterator, and only one call of "len". Gaining probably twice the
speed.


But is it really necessary to use classes and instance methods instead
of just plain methods in a module? A template should be stateless. (we
have render_context for the state when required.) Classes always have
overhead compared to methods.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation

[Jonathan Slenders]

Another one:

Instead of:
def has_key(self,key):
for level in xrange(0,len(self._levels)) :
if self._levels[level].has_key(key) :
return True
return False

do:
def has_key(self,key):
return any((key in l) for l in self._levels)

Ony one "self" reference, and any-through-iterator is very fast, as
it's native python code (probably implemented in C). And lazy
evaluating.

It's challenging to understand your code. Maybe it's easier if you
explain in words-only how you want to implement inheritance.

-

My approach would be like this


For a template called 'x', create a dictionary 'x' with maps the block
names for this template to a func with it's matching implementation
code.
Somehow, a method render_block(name) should be made available. So when
a blocks are nested, one block should be able to call
render_block(other_name). The render_block method should do a lookup
in the dictionary for a block with this name, and call it.

Dynamic inheritance can easily be realized by replacing key/value
pairs in this dict by other implementations. Pass the original
implementation to the new implementation as an additional function
parameter. (As a curry.)

I guess it's fast, and can be cached in memory. For each rendering,
only a copy of the required template dictionaries have to be made.
(Not even a deep copy.)

---

Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation , draft 2

[Jonathan Slenders]

Like Russ Magee said, Armin has a lot of experience in this field and
even if he didn't yet decided how to implement a compiled engine for
Django templates, I'm sure he will do a good job on this.

But that certainly doesn't mean that you shouldn't try as well (Even
when it's not accepted for GSoC). We'll see what the outcome is, and
the best one (in terms of stability and cleanness of the code.) can be
merged in Django. That's how open source works. For some stuff,
several people implement it, and the community gets the choice.

You learn damn a lot by writing a parser or compiler, but it can
sometimes take many times of refactoring and rewriting code before you
get a satisfying enough result.

By the way, someone in this group said that l10n takes a lot of time
during template rendering. I wonder what we can do about that...

Have a nice day,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: DDN: #2594 (Template system whitespace) may cause blocktrans issue

[Jonathan Slenders]

Some concerns, even if I don't know much about the subject.

Are you sure that it's always appropriate to strip indentation? Some
companies (like us) use templates for other stuff than HTML. (like
plain text mail.) In this case the indentation is meaningful (not to
the translator, but important for the actual output.) I understand
that in most cases, it's ugly to have the indentation and leading/
trailing whitespace in the msgid, but it's not always appropriate to
strip these whitespace characters.

Personally, I prefer more explicit whitespace control [1].

Anyway, I don't know much about this subject

[1] http://jinja.pocoo.org/docs/templates/#whitespace-control

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Fixing makemessages for Javascript

[Jonathan Slenders]

A related question.

How should we thread escape characters when the msgid is generated?
Is the escaping backslash assumed to be part of the translation?
And is this behaviour consistent between Babel and the current parser?

gettext("xy\"zzy 3");

In my opinion, we should completely unescape the gettext string before
doing the translation, and escape it again afterwards.


I'm asking this because I'm going to implement gettext preprocessing
in the template preprocessor and I'd like all implementations to be
compatible.
Basically, when this works, the i18n catalog for javascript is no
longer required, even for external files.
https://github.com/citylive/django-template-preprocessor

cheers,
Jonathan


On 18 avr, 00:14, Ned Batchelder  wrote:
> On 4/15/2011 12:40 PM, Russell Keith-Magee wrote:
>
>
>
>
>
>
>
> > On Fri, Apr 15, 2011 at 9:25 PM, Ned Batchelder  
> > wrote:
> >> On 4/14/2011 11:40 PM, Russell Keith-Magee wrote:
>
> >> Keep in mind that the proposal is not to include Babel, but to depend on it
> >> as a prerequisite, which means we are stuck in the same situation we are
> >> with gettext: it can change independently of Django, and new versions can
> >> introduce new bad behavior.  That's one of the reasons we have a bad 
> >> problem
> >> today: gettext changed from 0.17 to 0.18, and exacerbated the hack.
> > This is true. However, what you're proposing is, IMHO, a slightly
> > worse situation.
>
> > Babel is a self contained tool. Assuming it work as advertised (and
> > I'll grant that is a big and important assumption), it is a self
> > contained body of code. It is a dependency, but as long as it
> > continues to work as advertised, we're fine. We're only dealing with
> > it's advertised interface, and working with that interface in the way
> > it was intended to be worked with.
>
> > On the other hand, gettext is also a dependency, and gettext can also
> > change between releases -- but we're not using it as intended. We're
> > bending the Perl parser (or, in your case, the C parser) in strange
> > and unusual ways to do something it wasn't originally intended to do.
> > Something completely innocuous can change in gettext, and the
> > follow-on effect to us can be huge because we've built our castle on
> > an unstable foundation.
>
> I'm not much concerned that the C parsing in gettext will change
> significantly, but I take your point, it certainly could change behind
> our backs and we could be broken again.
>
>
>
>
>
>
>
>
>
> > The maintenance issue is the critical part here. My hesitation isn't
> > just to do with the suitability of your code *right now*. It's to do
> > with the fact that once we adopt the code into trunk, we are to
> > agreeing to maintain it. Bits don't rot, but gettext has already
> > demonstrated that it changes between versions, so it's reasonable to
> > assume that when gettext 0.19 is released (whenever that happens),
> > we'll need to make changes to our Javascript parser. By taking on the
> > lexer, we're absorbing into Django a whole bunch of project
> > responsibility that frankly, I'd rather we didn't have.
>
> >> Babel
> >> has the advantage that it is pure Python, so it is both more installable
> >> than gettext, and is more readable for us.  It also has the advantage that
> >> it isn't based on a hack, but that doesn't mean it performs flawlessly.
>
> >>> If the proposed patch was leaning on a well established lexer, or was
> >>> a simple configuration change (i.e., "treat it as C, not Perl") that
> >>> could be quickly demonstrated to fix a bunch of problems without
> >>> introducing any obvious new problems, I'd be all in favor of it as a
> >>> temporary solution. But that's not what is on the table -- it's a
> >>> complex body of code that we're proposing to evaluate, introduce,
> >>> maintain, and potentially deprecate very quickly.
>
> >> While the patch I've submitted is certainly larger than a configuration
> >> change, and is not a well-established lexer, I have "quickly demonstrated
> >> that it fixes a bunch of problems without introducing any obvious new
> >> problems", or at least, no one has come forward with a new problem.  I've
> >> paid a bounty on Stack Overflow for people to find problems in the lexer
> >> itself, which they have done, and those problems have been fixed.
> >