Re: Proposal: A diagram showing Class Based View inheritance and mixins.

[mjl Martin J. Laubach]

  I've used this one http://epydoc.pythondiary.com/generic-views/ with good 
results. Very low-level but totally useful.

mjl



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

Re: manage.py and pyc's

[mjl Martin J. Laubach]

  Well, the sneaky workaround would probably be to ship a totally simple 
management/commands/foo_command.py that does nothing more than "from 
only_as_pyc import *". Would that work for your use case?

mjl

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

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

[mjl Martin J. Laubach]

> In addition to the previous answers, I find it important to have an 
unambiguous __unicode__ / __str__, and name isn't necessarily unique. 

  Perhaps to have it a tiny little bit more useful, have it default to 
"MyModel object (object_pk)" ?

mjl

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

Re: django and paramstyle: what's the actual story?

[mjl Martin J. Laubach]

  As for the death of '%s' style -- yes please, with sprinkles on top. It 
is totally violating the principle of least astonishment as anyone will 
expect '%s' to expand to a parameter string; yet that's not what it does, 
it magically adds quotes and whatnot.

  The other two variants are widely understood.

mjl

-- 
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: Feature request: collectstatic shouldn't recopy files that already exist in destination

[mjl Martin J. Laubach]

Good idea, but shouldn't it be a per-storage thing? Perhaps this could be 
done with a couple of callbacks in the collectstatic run:

   - Before collectstatic starts, so the storage backend can pick up its 
   inventory from the remote
   - One called for each file that would be copied, and that can veto a 
   copy operation
   - At the end of the collectstatic run, to update the inventory

That would make things customisable even for strange setups like storing 
files in a database or whatnot?

   Cheers,

mjl

-- 
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/-/DLpjFU0NS_4J.
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's CVB - Roadmap?

[mjl Martin J. Laubach]

>
> This is the real issue. The docs.


  It's one of the issues, but I'm not really convinced it is the only 
one. My experience with CBV usually has gone like this:


   1.   "I need a view, let's do it with CBV"
   2.   "Oh hey, that was easy!"
   3.   "I need some more functionality" 
   4.   Go to the source and wade through it for an hour or so to find out 
   how
   5.   "Dang, those mixins conflict / don't work for my case / turn into a 
   confusing patch and overridefest"
   6.   "I wish I had just used a regular view, I would have been done long 
   ago"
   7.   (optional) Move to regular views
   

  I'm on the edge whether I'm too stupid or CBVs are too confusing to be 
worth it.

mjl

-- 
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/-/D4y3Cny5SHgJ.
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: discrepancy in default CSRF settings

[mjl Martin J. Laubach]

>
> However, it seems that the defaults are to add the middleware, but not the 
> context processor. Is there a specific reason for this?
>

  The docs say:
 

In the corresponding view functions, ensure that the 
'django.core.context_processors.csrf' context processor is being used. 
Usually, this can be done in one of two ways:

   1. Use RequestContext, which always uses 
   'django.core.context_processors.csrf' (no matter what your 
   TEMPLATE_CONTEXT_PROCESSORS setting). [...]

Cheers,

mjl


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

[mjl Martin J. Laubach]

>
> foo bar {#
>> #}baz 
>>
>>
>> You just made a strong argument against multiline tags: I wouldn't want 
> to see them abused this way!
>

  Ah, I fully expected to be shot down on "aesthetic" reasons. I still 
think it's better to have some (maybe slightly ugly) way to do things than 
no way and revelling in perceived beauty, and if it's as easy as the above, 
well, then so be it.


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

[mjl Martin J. Laubach]

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 


mjl 

-- 
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/-/R-wdFVTvxGAJ.
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.