Re: Proposal: add request decompression to gzip middleware

[Mikhail Korobov]

Request decompression looks scary: how are you going to implement 
protection against zip bombs (http://en.wikipedia.org/wiki/Zip_bomb)? See 
also: http://bugs.python.org/issue16043

суббота, 25 мая 2013 г., 20:34:44 UTC+6 пользователь Sébastien Béal написал:
>
> Hi,
>
> I would like to suggest to add requests decompression to the gzip 
> middleware. Although few browsers have the ability to compress the request 
> body, some use cases exists with other type of clients when building REST 
> APIs or WebDAV  clients.
>
> To my knowledge, only Apache 
> mod_deflate was 
> providing this feature.
>
> The idea behind this is simply to decompress the body of requests 
> containing Content-Encoding: gzip header. 
> I provided a working example on this branch: 
> https://github.com/sebastibe/django/tree/gzip-request-middleware
>
> What do you think about this?
>

-- 
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: Tests of contrib apps

[Mikhail Korobov]

среда, 20 марта 2013 г., 21:22:10 UTC+6 пользователь Aymeric Augustin 
написал:
>
> On 20 mars 2013, at 11:22, Russell Keith-Magee 
>  
> wrote: 
>
> > Personally, I'd rather see the opposite -- contrib apps containing their 
> own tests, and the tests directory containing just the tests for Django 
> itself. That enforces the fact that the apps really are self contained 
> apps, and can be tested independently. 
>
> > The catch -- and the reason why the tests are broken up the way they are 
> -- is that the test framework isn't currently rich enough to support this. 
> Admin is the best example of this -- in order to test admin, you need 
> different test models in different test apps, and the current test 
> framework doesn't support this very well. 
>
> Ah, I didn't know that was the reason. I assumed it was just because of 
> history... 
>
> > This really points at a deficiency in Django's testing tools that really 
> should be addressed. It's something I've wanted to look at for a while, but 
> I've never got around to it. It's also something that's likely to be easier 
> when the app refactor lands, because a lot of the problem lies in the app 
> cache. 
>
> > The point about not running the tests under ./manage.py test is a 
> slightly moot point if we move to the unittest2 discovery mechanism -- last 
> time I looked at that patch, unittest2 discovery would mean that contrib 
> tests wouldn't be run (by default) in a project anyway. 
>
> If these features were implemented, yes, they would bring the benefits I 
> listed. 
>
>
> There are a few other advantages in my proposal: 
>
> - Most users don't need the tests. Moving them apart will make Django 
> tarballs smaller. For example, auth has as more tests than code (120kb vs 
> 100kb), and admin has nearly twice as much tests than code (420kb vs 
> 220kb). 
>

Currently all tests are a part of tarball, so moving tests out of contrib 
won't make tarballs smaller.
 

>
> - Shipping tests for half of the contrib apps is worse than not shipping 
> any tests at all. Users who notice will think either we have poor coverage 
> or our packages aren't built correctly. Users who don't notice may falsely 
> believe that Django's tests pass for all the contrib apps they use with 
> their settings, which may not be true. 
>
> - The convenience of having all the tests in one directory at the toplevel 
> must be balanced with the philosophical correctness of dispatching them in 
> seventeen directories, four-levels-deep, which may themselves contain 
> entire app structures -- "flat is better than nested". 
>
> - It would help in the short term :) 
>
> -- 
> 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: Proposal: deprecate and remove django.contrib.comments

[Mikhail Korobov]

A good idea, +1.

четверг, 7 марта 2013 г., 22:48:11 UTC+6 пользователь Jacob Kaplan-Moss 
написал:
>
> Hi folks -- 
>
> This one's simple: I'd like to deprecate `django.contrib.comments`, 
> scheduling it to be removed in a couple of releases. 
>
> My rationale is this: if you don't really care much about how comments 
> work but just want something easy, then Disqus (and its competitors) 
> are easier to use and have much better features (spam prevents, 
> moderation, etc.). If you want something complex and specific, on the 
> other hand, you're better off writing something from scratch. 
>
> Practically, I'd do this by deprecating `django.contrib.comments` in 
> 1.6. We'd immediately stop making any changes to it (except for 
> security or data loss issues). It'd stay deprecated in 1.7, and would 
> be removed in 1.8. 
>
> If someone volunteers to maintain it as an external project I'll move 
> the code to a new repo and direct people there in the docs. If nobody 
> volunteers, then it'll go to the great /dev/null in the sky. 
>
> Any objections? 
>
> 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.

Re: python_2_unicode_compatible pitfalls

[Mikhail Korobov]

пятница, 28 декабря 2012 г., 14:37:46 UTC+6 пользователь Aymeric Augustin 
написал:
>
> 2012/12/28 Karen Tracey 
>
>> On Thu, Dec 27, 2012 at 7:15 PM, Aymeric Augustin <
>> aymeric@polytechnique.org > wrote:
>>
>>> 2) under Python 2.x __str__ is implemented as __unicode__
>>>encoded to utf8.
>>>
>>>
>>> Yes, this is a legacy behavior that I strongly disagree with. It
>>> makes __str__ / __unicode__ handling for Model subclasses
>>> exceedingly sketchy.* The only reason why I didn't remove
>>> it is backwards compatibility.
>>>
>>
>> I'm curious what would you do instead, if backward-incompatibility were 
>> not a concern?
>
>
> In Python __unicode__ is __str__ + decode(sys.getdefaultencoding()):
> http://docs.python.org/2/reference/datamodel.html#object.__unicode__
>
> Django reverses this behavior for Model subclasses and uses utf-8.
>
> I was first exposed to unicode handling in Python via Django and
> it took me a long time to discover that writing a __unicode__ method
> wasn't the canonical way to define an object's string representation.
>
> If we set aside backwards-compatibility, I would probably
> define a conventional, Django-specific method (eg. __display__)
> and derive __unicode__ and __str__ from there, according to
> Django's rules. Not using Python's default names makes it explicit
> that Django adds specific behavior. This vastly simplifies the
> definition of __str__ and __unicode__ in Python 2 and 3, and also
> avoids the semantic issue of __str__ returning unicode on Python 2
> under @python_2_unicode_compatible.
>
> An alternative would be to provide an explicit way to change
> Python's behavior -- either a decorator or a class attribute.
> Though this isn't going to be very DRY.
>
> I haven't had issues with using utf-8 instead of the system charset,
> but Mikhail seems to suggest it can be a problem on Windows.
> Using the system charset, like Python does, might be less surprising.
> I don't have enough experience to tell. This won't be a problem for
> displaying objects in templates, because they're rendered in unicode.
>
>
There is no a single "system charset" and that's the problem :) 

>>> import sys>>> import locale>>> sys.getdefaultencoding()'ascii'>>> 
>>> locale.getpreferredencoding()'cp1251'>>> sys.stdout.encoding'cp866'

(REPL in Windows XP with Russian locale with all defaults; 
sys.stdout.encoding would be None for scripts). It is not possible (as far 
as I can tell) to encode __str__ or __repr__ results to some encoding 
(except 7bit ascii) and expect it to work reliably.

 

> -- 
> Aymeric.
>
>

-- 
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/-/Tl53rAjzILQJ.
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: python_2_unicode_compatible pitfalls

[Mikhail Korobov]

Hi Aymeric,

FYI: I didn't check anything in my message manually, this is a "code 
review" based on grepping over django source code for common problems. 

пятница, 28 декабря 2012 г., 6:15:06 UTC+6 пользователь Aymeric Augustin 
написал:
>
> Hi Mikhail,
>
> Thanks for your feedback! Your email touches many topics; can we try
> to extract the most important ones and identify what really needs fixing
> before the 1.5 release?
>
> 1) @python_2_unicode_compatible doesn't handle __repr__.
>
>
> Indeed, this decorator isn't designed to handle __repr__ -- I haven't
> even tried.
>
> At first sight, I'd say this isn't a sufficient reason to delay the 1.5 
> release,
> but it's a feature we should consider for 1.6.
>
>For example, this affects django.db.models.options.Options,
>django.core.files.base.File (and ContentFile),
>django.contrib.admin.models.LogEntry, django.template.base.Variable
>and probably many others (their __repr__ incorrectly returns unicode).
>
>
>  

> Is it a regression in 1.5? Or did the problem already exist?
>
>
This is a regression. It is not very serious (the unicode would contain 
only ascii characters in all the cases above), but it may have some subtle 
consequences, and it seems that these methods was written as returning 
unicode intentionally (e.g. LogEntry.__repr__ 
returns smart_text(self.action_time), not str(self.action_time)). 

Oh, and my late night review of Model.__repr__ was not correct 
:) six.text_type(self) has nothing to do with encoding/decoding, it calls 
__unicode__ method and __repr__ returns utf8-encoded text as it supposed.

 
 

> 2) under Python 2.x __str__ is implemented as __unicode__
>encoded to utf8.
>
>
> Yes, this is a legacy behavior that I strongly disagree with. It
> makes __str__ / __unicode__ handling for Model subclasses
> exceedingly sketchy.* The only reason why I didn't remove
> it is backwards compatibility.
>
> * I expect future maintainers, including myself, to hate this:
> https://github.com/django/django/commit/2ea80b94
>
> This breaks 'print django_obj' when sys.stdout.encoding
>is not utf8 because print uses __str__ (not __unicode__) for custom 
> objects,
>and the terminal expects the result to be encoded in sys.stdout.encoding
>(print encodes unicode strings to sys.stdout.encoding, but doesn't
>use __unicode__ of objects; this is hard-coded in Python 2.x). 
>This may affect REPL in Windows consoles and printing/writing to stdout 
>in management commands.
>
>
> Django often defaults to utf-8 rather than try to figure out the
> most appropriate charset. Such code generally dates back
> to the unicode branch. So, yeah, this problem exists but it's
> not really new.
>
>
Defaulting to utf8 is better than trying to figure out the most appropriate 
charset, I fully agree with that (but prefer 7bit ascii myself which is not 
guessing). However, this makes REPL and printing not usable in environments 
where sys.stdout.encoding is not utf8. User usually expects to be able to 
type an object in console to check it, and this won't work (it may raise an 
exception or produce mangled output) under Windows (and some older *nixes) 
when there is a non-ascii data. Isn't it a bug? If it is not a bug, and it 
is an intended behavior that wouldn't be fixed (is backwards compatibility 
the only issue?), then maybe it should be documented ("sorry, we don't 
support cmd.exe under Python 2.x") to save developers time? Or maybe there 
are workarounds that would fix this? Currently REPL may fail because of 
django behavior, not because of buggy evil Windows or Python 2.x bugs, so 
IMHO it is django responsibility to either fix it or tell users what to do. 

 

>
> 3) @python_2_unicode_compatible produces incorrect results 
>when applied twice (__str__ is patched by previous decorator 
> application 
>and returns bytestring because of that).
>This is easy to oversight e.g. when applying this decorator to a
>subclass of a class which is wrapped to @python_2_unicode_compatible
>and deleting the overridden __str__ afterwards.
>
>
> This is a good point. I looked at the `_was_fixed` technique you're
> proposing below. It does work in more cases, but I'm pretty sure
> you can still break it by overriding __str__ or __unicode__ in a
> sufficiently complex class hierarchy.
>
>
>
__unicode__ becomes pretty internal with @python_2_unicode_compatible, and 
overriding it may break things. I was about to introduce checking for 
overridden __unicode__ (by something like adding _nltk_is_generated 
attribute), but decided not to be too smart (there may be reasons to 
override __unicode__ I don't know about).

On the other hand, overriding __str__ is fully legit. Can you please create 
an example on how can __str__ be broken in complex class hierarchy with 
_was_fixed?

4) __str__ is not always properly implemented for this decorator in django
>code. To work properly with @python_2_unicode_compatible,
>

Re: python_2_unicode_compatible pitfalls

[Mikhail Korobov]

Oh, my description of (5) is not totally correct: u'%r' % bytestring_value 
is fine because repr(non_ascii_bytestring) is an escaped 7bit ascii; this 
mean HttpResponseBase._convert_to_charset is almost fine (bytes would be of 
incorrect encoding, but this won't raise an exception). The argument about 
"%r" % object_with_non_ascii__repr__ still apply.

пятница, 28 декабря 2012 г., 1:20:24 UTC+6 пользователь Mikhail Korobov 
написал:
>
> Hi there,
>
> First of all, many kudos for the Python 3.x support in upcoming django 
> 1.5, and for the way it is handled (the approach, the docs, etc)! 
>
> I think there are some pitfalls with 
> @python_2_unicode_compatible decorator as it currently implemented in 
> django (and __str__/__repr__ in general), and want to share the thoughts 
> before the 1.5 release. I'm sorry that this message is pretty vague; it 
> points to some problems with the current approach (some of them are real, 
> some would occur very rarely) but it doesn't propose  the solution for 
> django other than "please review the code once more".
>
> 1) @python_2_unicode_compatible doesn't handle __repr__.
>For example, this affects django.db.models.options.Options,
>django.core.files.base.File (and ContentFile),
>django.contrib.admin.models.LogEntry, django.template.base.Variable
>and probably many others (their __repr__ incorrectly returns unicode).
>
>It also may be the cause why django.db.models.Model.__repr__ doesn't
>follow Python conventions ("__repr__ should be information-rich and
>unambiguous" - unicode values are replaced with "[Bad Unicode data]").
>By the way, the way django detects whether value needs replacing 
>is not correct and doesn't prevent all errors because what
>"u = six.text_type(self)" do for bytestring is decode data using
>sys.getdefaultencoding() while repr is (most?) often used in console,
>where sys.stdout.encoding matters.
>
> 2) under Python 2.x __str__ is implemented as __unicode__
>encoded to utf8. This breaks 'print django_obj' when sys.stdout.encoding
>is not utf8 because print uses __str__ (not __unicode__) for custom 
> objects,
>and the terminal expects the result to be encoded in sys.stdout.encoding
>(print encodes unicode strings to sys.stdout.encoding, but doesn't
>use __unicode__ of objects; this is hard-coded in Python 2.x). 
>This may affect REPL in Windows consoles and printing/writing to stdout 
>in management commands.
>
> 3) @python_2_unicode_compatible produces incorrect results 
>when applied twice (__str__ is patched by previous decorator 
> application 
>and returns bytestring because of that).
>This is easy to oversight e.g. when applying this decorator to a
>subclass of a class which is wrapped to @python_2_unicode_compatible
>and deleting the overridden __str__ afterwards.
>
> 4) __str__ is not always properly implemented for this decorator in django
>code. To work properly with @python_2_unicode_compatible,
>__str__ must return unicode string. This is quite subtle.
>For example, take a look at django.contrib.gis.maps.google.GEvent.
>__str__ is implemented as 
>"return mark_safe('"%s", %s' %(self.event, self.action))",
>but "from __future__ import unicode_literals" is not applied to the 
> file.
>This means that if event and action are Python objects with both __str__
>and __unicode__ methods defined (e.g. object of class wrapped with
>python_2_unicode_compatible) then __str__ would be called for these 
> objects,
>not __unicode__ (because the format string is a bytestring). Generally,
>"%s" % something is a good and correct pattern for __str__ 
> implementation
>(it does the right thing under both Python 2.x and 3.x when
>unicode_literals future import is there), but it is incorrect under 
> Python
>2.x if unicode_literals is not imported.
>
> 5) %r is very tricky. If unicode_literals are in effect, or some 
>arguments for string formatting are unicode,
>"%r" % obj would trigger bytes decoding using sys.getdefaultencoding() 
> under
>Python 2.x (unless obj is an unicode string), and if obj.__repr__ 
> returns
>non-ascii text or obj is a bytestring, exception would be raised
>(because sys.getdefaultencoding() is usually ascii).
>This format specifier is used, for example, in a default_error_messages
>for django.db.models.fields.Field; after switching to unicode_literals
>this may start raising UnicodeDecodeExceptions for non-ascii choices
>if they are custom objects (not unicode strings).
>Another example is 
>

python_2_unicode_compatible pitfalls

[Mikhail Korobov]

Hi there,

First of all, many kudos for the Python 3.x support in upcoming django 1.5, 
and for the way it is handled (the approach, the docs, etc)! 

I think there are some pitfalls with @python_2_unicode_compatible decorator 
as it currently implemented in django (and __str__/__repr__ in general), 
and want to share the thoughts before the 1.5 release. I'm sorry that this 
message is pretty vague; it points to some problems with the current 
approach (some of them are real, some would occur very rarely) but it 
doesn't propose  the solution for django other than "please review the code 
once more".

1) @python_2_unicode_compatible doesn't handle __repr__.
   For example, this affects django.db.models.options.Options,
   django.core.files.base.File (and ContentFile),
   django.contrib.admin.models.LogEntry, django.template.base.Variable
   and probably many others (their __repr__ incorrectly returns unicode).

   It also may be the cause why django.db.models.Model.__repr__ doesn't
   follow Python conventions ("__repr__ should be information-rich and
   unambiguous" - unicode values are replaced with "[Bad Unicode data]").
   By the way, the way django detects whether value needs replacing 
   is not correct and doesn't prevent all errors because what
   "u = six.text_type(self)" do for bytestring is decode data using
   sys.getdefaultencoding() while repr is (most?) often used in console,
   where sys.stdout.encoding matters.

2) under Python 2.x __str__ is implemented as __unicode__
   encoded to utf8. This breaks 'print django_obj' when sys.stdout.encoding
   is not utf8 because print uses __str__ (not __unicode__) for custom 
objects,
   and the terminal expects the result to be encoded in sys.stdout.encoding
   (print encodes unicode strings to sys.stdout.encoding, but doesn't
   use __unicode__ of objects; this is hard-coded in Python 2.x). 
   This may affect REPL in Windows consoles and printing/writing to stdout 
   in management commands.

3) @python_2_unicode_compatible produces incorrect results 
   when applied twice (__str__ is patched by previous decorator application 
   and returns bytestring because of that).
   This is easy to oversight e.g. when applying this decorator to a
   subclass of a class which is wrapped to @python_2_unicode_compatible
   and deleting the overridden __str__ afterwards.

4) __str__ is not always properly implemented for this decorator in django
   code. To work properly with @python_2_unicode_compatible,
   __str__ must return unicode string. This is quite subtle.
   For example, take a look at django.contrib.gis.maps.google.GEvent.
   __str__ is implemented as 
   "return mark_safe('"%s", %s' %(self.event, self.action))",
   but "from __future__ import unicode_literals" is not applied to the file.
   This means that if event and action are Python objects with both __str__
   and __unicode__ methods defined (e.g. object of class wrapped with
   python_2_unicode_compatible) then __str__ would be called for these 
objects,
   not __unicode__ (because the format string is a bytestring). Generally,
   "%s" % something is a good and correct pattern for __str__ implementation
   (it does the right thing under both Python 2.x and 3.x when
   unicode_literals future import is there), but it is incorrect under 
Python
   2.x if unicode_literals is not imported.

5) %r is very tricky. If unicode_literals are in effect, or some 
   arguments for string formatting are unicode,
   "%r" % obj would trigger bytes decoding using sys.getdefaultencoding() 
under
   Python 2.x (unless obj is an unicode string), and if obj.__repr__ returns
   non-ascii text or obj is a bytestring, exception would be raised
   (because sys.getdefaultencoding() is usually ascii).
   This format specifier is used, for example, in a default_error_messages
   for django.db.models.fields.Field; after switching to unicode_literals
   this may start raising UnicodeDecodeExceptions for non-ascii choices
   if they are custom objects (not unicode strings).
   Another example is 
django.http.response.HttpResponseBase._convert_to_charset
   where BadHeaderError exception is raised: after switching to 
unicode_literals
   %r format specifier start triggering decoding of "value" using 
sys.getdefaultencoding()
   which is incorrect because "value" is a bytestring of 'charset' encoding 
under
   Python 2.x. Another example is django.utils.datastructures.SortedDict:
   its __repr__ uses '%r: %r' % (k, v) for k, v in six.iteritems(self)
   which may fail if key is an unicode string and a value is a bytestring
   or an object with __repr__ returning non-ascii text. Another example
   is django.utils.encoding.DjangoUnicodeDecodeError
   (it has incorrect __str__ by the way because it returns unicode) -
   it uses "%r" for self.obj, with unicode string formatter,
   and this would blow up if __repr__ of obj returns non-ascii text.
   There are other places where %r is used and they all are fragile.

I've implemented 

Re: Python 3: should we apply unicode_literals everywhere?

[Mikhail Korobov]

Python 3.2 is a default python in Ububtu 12.04 LTS so I think Python 3.2 
support is pretty important. 

And what are the gains of having "u" prefixes all over the codebase? This 
makes the codebase less Python3-like. With PEP414-based code there must be 
explicit "b" and explicit "u" prefixes all over the code; the sweet 
unprefixed variant will be reserved for "naive strings" which are rarely 
useful. With unicode_literals explicit "b" prefix is needed if byte strings 
and explicit "str(foo)" call is needed for "native strings"; unicode 
strings are implicit and default in both Python 2.x code and Python 3.x 
code. This is more porting work but I think it is more rewarding because it 
leads to a cleaner code.

среда, 22 августа 2012 г., 21:06:37 UTC+6 пользователь VernonCole написал:
>
> That seems to me (in my dark status as a lurker here) to be a brilliant 
> idea. 
> It is already established practice to say something like: "version 1.n of 
> django requires 2.m or later of Python".
> The practice then would change to: "version 1.n of django requires 2.m of 
> Python or 3.3 or later".
> I see from reading the text of PEP414 that there is an import hook 
> available to make this feature also work in Python 3.2.
> Would there be any advantage to requiring support for older versions of 
> Python 3?  I can't think of any.
> Python 3.3 will be an established thing long before a django version using 
> it gains production status. We developers can use hooks and beta versions.
> --
> Vernon Cole
>
> On Tuesday, August 21, 2012 4:03:57 PM UTC-6, DrMeers wrote:
>>
>> It's a shame we couldn't skip straight to Python 3.3 and take 
>> advantage of PEP414... 
>>
>> On 22 August 2012 07:32, Adrian Holovaty  wrote: 
>> > On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin 
>> >  wrote: 
>> >> In my opinion, option (2) is a logical move at this point. However I 
>> >> believe it deserves a public discussion (or at least an explanation). 
>> >> What do you think? 
>> > 
>> > I prefer option 2 as well, because it seems like the Right Thing To 
>> > Do. Of course, there's no rush to do everything -- we can just nibble 
>> > off bits here and there. 
>> > 
>> > I'll have some free time soon and would be happy to help out migrating 
>> > code. (Relatively) mindless refactoring like this is one of my 
>> > favorite things to do. :-) 
>> > 
>> > Adrian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Django developers" group. 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > To unsubscribe from this group, send email to 
>> django-develop...@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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/m94CZ4GZxLsJ.
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: new syntax for management commands

[Mikhail Korobov]

Some people prefer argparse, some people prefer decorator-based syntax 
(like django-boss or argh), there are people prefer other methods (e.g. 
docopt). I think it is better not to invent yet another command-line 
framework. 

Maybe delegate option parsing to user favorive library and provide some 
basic utilities for management command registration and execution 
instead? I didn't think of API yet, but the idea is:

- django code setups settings, validates models, activates proper 
translation, maybe manages transactions.
- developer registers management command (so it works in e.g. ./manage.py 
help and call_command); implements some interface (e.g. 'run_from_argv' and 
'help' methods); parse options in 'run_from_argv' and do whatever needed.


воскресенье, 12 августа 2012 г., 16:32:49 UTC+6 пользователь Florian 
Apolloner написал:
>
> Hi,
>
> On Sunday, August 12, 2012 2:22:58 AM UTC+2, Russell Keith-Magee wrote:
>>
>> I'll agree that it looks appealing. However, as always, my question is 
>> about backwards compatibility. 
>>
>
> Seriously? In my eyes it's ugly, especially if you have more than one 
> options. Eg imagine you have decorated a function with @argument 6 times. 
> Even though make_option isn't much better in that way I think that a class 
> looks nicer and is easier to skim over. 
>
> Maybe usage of argparse might improve a few things to write complex 
> management commands (eg subparsers, 
> http://docs.python.org/dev/library/argparse.html#argparse.ArgumentParser.add_subparsers)
>  
> -- although it's 2.7+
>
> Cheers,
> Florian
>

-- 
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/-/aAUIxq8u5E8J.
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?

[Mikhail Korobov]

If you pollute the namespace with small helper functions you can test them 
independently and use them outside single CBV. This style also helps to 
write less coupled code - all dependencies are visible (they are all in 
functions' params list) so this forces developer to rethink the 
decomposition and write small functions with less arguments (and thus less 
dependencies) and so such functions are more reusable and it is easier to 
test them because they need less state information and the output is (or 
should be) simpler.

This 'library' approach is opposite to 'framework' approach when you're 
given a class that almost solve your problem and then customize it to make 
it solve your problem. With 'library' approach you're given small building 
blocks and use them to implement the necessary logic. 

I think both approaches are useful in different circumstances. We shouldn't 
say one approach is superior to another. I personally found FBV and 
'library' approach to writing views suite my needs better but experience 
may vary.

-1 for rewriting to CBV for the sake of rewriting; +1 for adding a clear 
note to docs that FBVs are not deprecated. It seems there is a lot of 
confusion about this.

вторник, 5 июня 2012 г., 21:33:53 UTC+6 пользователь dstufft написал:
>
>  
>  On Tuesday, June 5, 2012 at 11:11 AM, Albert O'Connor wrote:
>
> Both the Built in Generic Class Based Views, and Class Based Views
> in general are great. Generic Class Based Views are not awesome when
> your view is not generic.
>
>
> My experience is using Generic Class Based Views as an inspiration for
> ones own Class Based Views lead to a bad user experience, both for
> myself and apparently other people. I think it is worth highlight in
> the documentation that Generic Class Based Views are useful, but
> apparently not how you should write your own.
>
> The GCBV's tried to go very far into reusability, to the point where they
> have several layers of indirection to what is going on. Personally I prefer
> a case where you have the base view which is well written and contains
> all of the "Base" functionality instead of having a base view which
> is actually comprised of half 3-6 different Mixins.
>
> However adopting some of their conventions into your own CBV's will
> go a long way (get_object, get_queryset etc). 
>
>
> Mixing in your UserMixin with other mixins that do additional query
> modifications will lead to the writer of code having to create new
> mixin which either combines both lines of code into one through
> copying or explicitly calling each mixin, which will itself be
> additional lines of code.
>
> This is only true if you write poor mixins. 
>
>
> I can see an argument for using CBV to create library views which are
> expected to both be reused and customized extensively, but those CBV
> should themselves be flat with a very clear execution model. Using
> inheritance to override behaviour with the syndication framework works
> because you only have to look at one class to see what behaviour you
> are modifying, but it doesn't scale to a any number of mixins, except
> many for the one your provide in your distinct use case.
>
> It should be noted a vast majority of views that developers write
> which aren't "generic" will never ever be reused and thus probably
> should be CBV.
>
> I assume you meant shouldn't be here. There are benefits beyond
> the reusability (which the reusability is something I speak a lot about),
> in terms of testing, breaking things into easier to digest chunks. Even
> the most non-generic view tends to create a good deal of boilerplate.
>
> Even something as simple as the default get() and post() methods
> reduces the amount go cognitive overhead needed while parsing
> what a view does.
>
> As an example a dummy: https://gist.github.com/2875669
>
> Similar number of lines (intact the CBV is a bit more), however with
> the CBV I've broken my view down into smaller chunks which, other
> then via self, are not able to affect one another. This allows me to focus
> on a much smaller unit of code if I am debugging making me have to
> "page" less of the application into my head at once. (As an example,
> maybe the post method accidentally reuses a variable from the setup
> code that the generic code was expecting to be there).
>
> Even if all you use the CBV's for is a "Namespace to hold crap" I feel
> that your code will end up better as it enables you to break apart a view
> into smaller and more manageable chunks, without polluting the views.py
> namespace with multiple functions for every view.
>
> Albert
>
> On Tue, Jun 5, 2012 at 10:46 AM, Donald Stufft  
> wrote:
>
> On Tuesday, June 5, 2012 at 10:35 AM, Carl Meyer wrote:
>
>
>
> On 06/05/2012 08:12 AM, Donald Stufft wrote:
>
> In order to do this with FBV's i'd either need to modify the existing
> FBV to accept
> a parameter that says if it should filter by logged in user or not or
> copy/paste
> the code into a new 

Re: Migrating to 1.4

[Mikhail Korobov]

Thanks man!

PASSWORD_HASHERS = ('django.contrib.auth.hashers.MD5PasswordHasher',)

in test_settings.py made tests of our project 2x faster (I was not 
upgrading from 1.3).

понедельник, 16 апреля 2012 г., 20:33:31 UTC+6 пользователь Dan Fairs 
написал:
>
> Hi,
>
> Both of these were fixed by using the new implementations from Django
>
> itself, and re-applying our small changes.
>
>
> Should I raise backwards-incompatibility tickets for these? They're pretty
>
> obscure, and I can't imagine many people are doing them. I raised #17891
>
> because the code involved a clear extension point.
>
>
> Thanks for sharing this story, Dan! It's great to hear. Let us know
> about the performance differences (if any), too.
>
>
> Well, we're finally getting into the performance side of things now!
>
> The first big regression for us was that our test suite took 20% longer to 
> run. I traced this down to the new default password hasher. This is clearly 
> by design - and we'll just use the PASSWORD_HASHERS setting to use a faster 
> (and much less secure) hasher for test runs.
>
> Fortunately our app uses an external authentication service for most of 
> its users, so this won't affect us in production - but for those running 
> sites with high signup rates, this could be a surprise. Is that worth a 
> mention in the release notes?
>
> Cheers,
> Dan
> --
> Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.com
>  
>

-- 
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/-/eu33GTCcgRQJ.
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: Dropping django.utils.simplejson

[Mikhail Korobov]

Standard python 2.6 json is a bundled and cleaned up simplejson without C 
extension and pre-26 compatibility - even if json serialization is not a 
common bottleneck why make things worse? Simplejson and python 2.6 json are 
arguably the same libraries, I think this is like choosing between 
cStringIO vs StringIO. 

суббота, 31 марта 2012 г. 3:03:00 UTC+6 пользователь Alex Ogier написал:
>
> I did some timing tests.  
> https://code.djangoproject.com/ticket/18023#comment:5
>
> An order of magnitude difference in JSON serialization time corresponds to 
> an 8% change in total serialization time for a complex model, and 5 deeply 
> nested model instances can be serialized in < 2 ms. It might be a little 
> different depending on how deeply your models are related, but it convinced 
> me that splitting hairs over the JSON serializer isn't worth it. I had the 
> idea in my head that serialization might be a bottleneck in the same way 
> that template rendering is, but I realize now it's very different. Heavily 
> nested and unoptimized templates thrash the disk and change a 10ms response 
> into a 100ms response. Shoddy JSON serializers might thrash the heap, or 
> make the GC work overtime, but it's all in memory so the worst that happens 
> is that a 10ms response becomes a 12ms response. It's just not worth 
> worrying about.
>
> Best,
> Alex Ogier
>
> On Fri, Mar 30, 2012 at 2:02 PM, Łukasz Rekucki wrote:
>
>> On 30 March 2012 13:04, Alex Ogier  wrote:
>> > At the same time, I want to reiterate my support for option #1: not 
>> deprecating the
>> > module and leaving the shim in for the foreseeable future. If 
>> simplejson is
>> > available on the system, and particularly if it has been compiled with C
>> > extensions, then there is a significant performance gain to be had, so 
>> why
>> > not continue to take advantage of that in all the places that django
>> > serializes to json?
>>
>> I agree this is a valid concern and I think it should be mentioned in
>> release notes. If you want more performance, then option #3 (anyjson)
>> would actually be better, but I don't think it should be Django's
>> concern to choose the best JSON package for you (we don't do that for
>> XML). Instead, imho, Django should provide an ability to pass a custom
>> JSON encode/decoder to all APIs that require it, so you can decide
>> about it at the project level.
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> 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 view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/edityP87yQQJ.
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: auth.User refactor: reboot

[Mikhail Korobov]

суббота, 17 марта 2012 г. 0:15:39 UTC+6 пользователь dstufft написал:
>
> On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote:
>
> Here's my hit list of perceived benefits:
> 1. It regains the efficiency of a single table (which is minor, to be 
> sure, but since Jacob already brought it up...)
>
> This issue isn't as minor as one might think I don't believe. I've 
> recently started using the fetch_related thing (which would be the only way 
> to prevent N queries when trying to select a bunch of users + their 
> profiles) and on a table with 20k entries (this isn't User related) where 
> the entries are fairly large the processing time to fetch them all was very 
> significant. This effect would increase with Tom's per app profile issue.
>

If the Profile model has OneToOne relation to User (as suggested in django 
docs [1]) then prefetch_related is not necessary, select_related can be 
used to get all records using single JOIN query. And storing more data in a 
single table could reduce performance, not increase it, because this data 
will be fetched by default even if it is not necessary (+ database will 
have larger rows to search in) - this effect would increase if there are 
several user profiles :) Storing all data in a single table is database 
denormalization: sometimes it can be benifical but should not be default in 
my opinion.

[1] 
https://docs.djangoproject.com/en/1.3/topics/auth/#storing-additional-information-about-users

-- 
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/-/1Bt6KG98h8wJ.
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: override_settings with dynamic model creation

[Mikhail Korobov]

Hi Alisue,

Django already have a way to create models only for tests: put model 
definitions to tests.py. Such models will be available in tests but won't 
be created with ./manage.py syncdb.

вторник, 28 февраля 2012 г. 9:11:25 UTC+6 пользователь Alisue написал:
>
> (2012年02月28日 01:34), Florian Apolloner wrote:
> > Hi,
> > 
> > On Monday, February 27, 2012 2:53:37 PM UTC+1, Alisue wrote:
> >>
> >> But I found that ``override_settings`` is available in dev version of 
> >> django. So I just wonder that if official django's 
> >> ``override_settings`` support dynamic model creation.
> > 
> > 
> > ``override_settings`` does exactly what the name says: It overrides 
> > settings -- there is nothing special done for models etc, it's just a 
> > convenient way to change settings and restore them back later on.
> > 
> > Cheers,
> > Florian 
> > 
> So you mean that ``override_settings`` should have minimum feature and
> should NOT do complicated things? That makes sense but I think django
> SHOULD HAVE some features for creating tables dynamically in test and
> when user override ``INSTALLED_APPS`` that mean the user want to use
> that app in test (or whatever) so I suggested.
>
> Well then how do you think that django's ``TestCase`` have
> ``required_apps`` attribute which is used to add required
> apps and create tables of the apps? In that case, ``override_settings``
> is not used for overriding ``INSTALLED_APPS`` and should raise warning.
>
> Thanks.
> Alisue
>
>

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

[Mikhail Korobov]

воскресенье, 26 февраля 2012 г. 15:38:33 UTC+6 пользователь Łukasz Rekucki 
написал:
>
> On 26 February 2012 05:55, Joe & Anne Tennies  wrote:
> > While this would be a valid argument if Django templates only rendered 
> HTML,
> > that is not the only thing it can be used to render.
>
> > The original poster gave a very good example of a text-based email.
>
> This is pretty much the only valid use-case: human-readable markup
> which cares about whitespace. But I don't see how multiline tags help
> here, as now you have a mix of text that does and doesn't care about
> whitespace, So when reviewing the template, you can't see the layout.
>
> > I could list lots of other formats in which white space must be followed 
> to even be useful (like .CSV).
>
> Please don't use templates to render CSV, that's like using regular
> expressions to parse XML. Most of data exchange and configuration file
> formats have libraries to serialize them. So no, that's not a use
> case.
>
This is in django docs: 
https://docs.djangoproject.com/en/1.3/howto/outputting-csv/#using-the-template-system
 

> > I have used Jinja2 on multiple occasions to render C code that needed to 
> be
> > code reviewed.
>
> While I have nothing against rendering C code with templates, I pity
> the person reviewing it - why would you force anyone to review
> auto-generated code?
>
> I'm -1 on this until someone actually provides a patch with no
> performance hit. Really, we know people fork Django for their private
> use. If this is such a big deal, we should have at least one person
> using this in production for a while now and have an excellent quality
> patch to show.
>
>
> -- 
> Łukasz Rekucki
>
>

-- 
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/-/sEHdyHf1L6cJ.
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: Moving to ... Github vs Bitbucket

[Mikhail Korobov]

A heavy bitbucket user here.

I personally prefer hg to git and bitbucket to github but I think github + 
git would be better for django because of much larger community.

Guys, but please stop bashing bitbucket. Bitbucket supports both hg and git 
(github don't), has nice bugtracker; bitbucket has hundreds of django 
packages on it (please don't call them unsignificant); it is in active 
development since Atlassian came, etc. Default repository landing page can 
be easily set to source browser in repository options. Hope this discussion 
won't become "github vs bitbucket" or "hg vs git" holywar.

-- 
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/-/Ybs6W1-ulvwJ.
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: #16630: Support for HTML5 input types

[Mikhail Korobov]

+1 for Paul's concerns. I think this at least should be opt-in. 

It can be also more or less implemented without custom widgets but 
using Gregor Müllegger's form-rendering branch (which is not merged but 
available as https://github.com/SmileyChris/django-forms app if I 
understand it properly) - or with some other external app like 
http://pypi.python.org/pypi/django-widget-tweaks/ 

среда, 28 декабря 2011 г. 10:15:49 UTC+6 пользователь poswald написал:
>
> I have a concern regarding this.. A few times I have tried to 
> integrate django-floppyforms which takes a similar approach to what 
> the html5 widgets offer (input types are specified by default) and it 
> often causes pain. The reason is that while browsers say they support 
> html5 input types sometimes that support is lacking or very badly 
> implemented. As an example, if you say  value="2011-12-28"> the only officially supported date format is an 
> RFC-3339 'full-date' format (-MM-DD) according to the spec: 
>
> http://dev.w3.org/html5/markup/input.date.html#input.date.attrs.value 
> http://tools.ietf.org/html/rfc3339 
>
> This means that you cannot have any other format of date string in 
> that form field. 
>
> Now, this ticket 16630 doesn't change the date field specifically but 
> it does change the number field. (Is there a similar ticket for 
> changing the date field?) I've run into a similar problem with the 
> type='number' that this ticket does change. The problem I ran into was 
> that forms cannot easily use the THOUSANDS_SEPARATOR because it is not 
> a valid number. It has to be a 'float' to be valid. This means 
> technically you need to use the text widget for that. 
>
> http://dev.w3.org/html5/markup/datatypes.html#common.data.float 
>
> So by my thinking this patch (and by extension the thinking of 
> browsers and the w3) is non-backwards compatible with the way that 
> django formats numbers when USE_THOUSANDS_SEPARATOR is True or when 
> localization is turned on. 
>
> https://docs.djangoproject.com/en/dev/ref/settings/#use-thousand-separator 
>
> Maybe there is something I'm missing here? I just want to flag this as 
> a concern and make sure that developers know what they are getting 
> into by enabling that. I would be for this being the default if it 
> could be disabled. That way, I can use modernizr.js and turn only 
> certain marked fields into type="number" or type="date". At the 
> minimum, we would need to document that the default behavior is 
> changing. 
>
> -Paul 
>
>
>
> On Dec 28, 1:35 am, Aymeric Augustin 
>  wrote: 
> > On 27 déc. 2011, at 17:15, Jonas H. wrote: 
> > 
> > > This patch has been around for while now. I just updated the patch so 
> it applies cleanly against rev 17281. 
> > 
> > > So, can we get this patch into trunk or is something missing? 
> > 
> > Hi Jonas, 
> > 
> > The patch looks pretty good, but it needs documentation: 
> > - in the widgets reference; 
> > - in the release notes, under backwards-incompatible changes. 
> > 
> > Best regards, 
> > 
> > -- 
> > Aymeric Augustin.

-- 
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/-/AUiKFrO2-0cJ.
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: Python 3 port - notes for people wanting to review changes/port apps

[Mikhail Korobov]

The similar applies to octal constant suggestion: If python 2.5 is not 
supported is may be better to replace 0777 with 0o777.

* http://docs.python.org/whatsnew/2.6.html#pep-3112-byte-literals
* 
http://docs.python.org/whatsnew/2.6.html#pep-3127-integer-literal-support-and-syntax

-- 
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/-/K8-qAdxoZusJ.
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: Python 3 port - notes for people wanting to review changes/port apps

[Mikhail Korobov]

Great effort!

What about using 

from __future__ import unicode_literals

instead of wrapping every constant with a "u" or "b" functions? 

Python 2.6 support 'b' notation so if python 2.5 is not supported there is 
no need for "u" and "b" functions.

-- 
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/-/KKdiCMaADb4J.
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: RFC: "universal" view decorators

[Mikhail Korobov]

I don't agree with most points because they are assuming functions are less 
fancy, less customizable, less clean, more complex, etc than classes and 
this is not true (but let's not start FP vs OOP holywar here, FP and OOP are 
friends in python).

I like Jacob's proposal because there should be one way to do something and 
this way can't be mixins because they can't work with functions. Decorators 
can work with classes, this is standard python and it will be nice to have 
them work with class-based views.

-- 
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/-/ZCeB1UehSSQJ.
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: PHP-inspired user-friendly in-browser DJango install

[Mikhail Korobov]

Hi all,

There are a lot of projects for making django deployment easier (a bit of 
them are listed here: http://djangopackages.com/grids/g/deployment/ ) but 
there is no clear winner, everybody have different preferences and 
requirements. I think this all doesn't relate to development of django 
itself now: if somebody have an idea for an another deployment app she 
should go and implement it and see if it will work for other people. 
Deployment approaches can be very different, they are subject to holy wars 
so I think for now the diversity is for good.

-- 
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/-/GJEiOX1eg80J.
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 a new templatetag definition syntax

[Mikhail Korobov]

I gave up defining this template tag with existing template tag libraries:

{% easy_map  [ ] [] [using ] %}


Can positional arguments be optional? Will it be possible to express this 
syntax?

-- 
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/-/-ZjMdkCLOS0J.
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: Multiple timezone support for datetime representation

[Mikhail Korobov]

Great job on summarizing the issue!

I have one concern though. Can you please explain why is USE_TZ option 
better than introducing e.g. UtcDateTimeField?

USE_TZ=True will break all existing code (including external apps) which 
relies on django 1.3 documented DateTimeField behavior, this can be scary 
and will introduce a lot of "if getattr(settings, USE_TZ, False): #..." 
statements in external apps for backwards compatibility.

Good UtcDateTimeField implementation can be released as a separate package 
(and then eventually included in django itself). This way existing django 
projects will be able to use it without waiting for a release and backwards 
compatibility won't be broken. Are there obstacles in django itself that 
prevent this option? 

-- 
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/-/3sUDTbi24PgJ.
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: What is Django?

[Mikhail Korobov]

Hi all,

One thing I always like about django is how the community is peaceful and 
how the django itself is peaceful and engineer-minded, not marketing-minded: 
I can't imagine whydjangoisbetterthanx.com website bashing zend, rails, 
pyramid and flask, for example. That's why the idea of putting something 
like "Django has a number of distinct, measurable advantages over similar 
web frameworks." to the djangoproject.org front page doesn't seems too 
attractive for me. 

There are many big and well-known sites built with django and I think 
mentioning these sites and providing testimonials from people working on 
these sites can be better advertisement. I respect the sites listed on 
djangoproject.org page very much but the selection is 
quite opinionated towards newspaper web sites, maybe disqus, mozilla addons, 
opera portal, yandex projects, meebo, etc. (not sure about the exact 
list) can build more trust in framework for newcomers. These are not typical 
django websites but I think they will impress people more. 

-- 
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/-/Jb_eQeXTr4YJ.
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 form-rendering] Weekly Check-in

[Mikhail Korobov]

Hi Gregor & others,

I've noticed the https://github.com/idangazit/formrendering and it reminds 
me the approach I'm using for all my django 1.3 projects:

{# forms/fields/as_dl.html #}
  {{ field.label_tag }}}   {{ field }}
{% include "forms/fields/errors.html" %}  

and then:

 {% csrf_token %} {% include 
'forms/fields/as_dl.html' with field=product_form.title %} {% include 
'forms/fields/as_dl.html' with field=product_form.conditions %}
 

This can be used in a loop:

{# forms/my_as_ul.html #}
{% include "forms/non_field_errors.html" %} 

{% for field in form %} 
{% include 'form/fields/as_dl.html' %} {% endfor %}


and then:

{% include 'forms/my_as_ul.html' with form=product_form %}

If individual field should be changed then django-widget-tweaks can be used:

{% load widget_tweaks %}
 {% csrf_token %} {% include 
'fields/as_dl.html' with field=form.title|attr:"autofocus" %}
{% include 'fields/as_dl.html' with 
field=form.conditions|add_class:"foo"|attr:"type:search" %}
{% include 'forms/buttons/submit.html' with value="Save" %} 

This approach does not provide all the sugar from the Idan's and Gregor's 
proposals (namely, it forces developer to list all fields if one field is to 
be tweaked) but it is quite simple, introduces no new concepts and can be 
used in existing django 1.3 projects.

-- 
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/-/fAq3shFikDMJ.
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: model fields options

[Mikhail Korobov]

Not exactly related, but this is how help_text (and other field options) can 
be moved out from the field definition without patching 
django: http://djangosnippets.org/snippets/2180/

-- 
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: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

[Mikhail Korobov]

I think the alternative for python 2.5 may be not to use urllib2 and set 
socket timeouts directly, this is supported from python 2.3 (basic 
implementation: 
https://bitbucket.org/kmike/vkontakte/src/e89d4cb94902/vkontakte/http.py ). 
Feels like a hack though.

-- 
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: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

[Mikhail Korobov]

@Fabiant

The code linked does not set global default socket timeout and so it 
shouldn't have concurrency issues; it sets socket timeout for HTTPConnection 
instance's socket.

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

deprecation of AUTH_PROFILE_MODULE

[Mikhail Korobov]

Hi folks, 

what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile() 
or removing the suggestion to use it from the docs in 1.4 release?
There are broader issues with extending User model but I think this one can 
be handled separately.

Some links:
* http://code.djangoproject.com/ticket/15937
* https://groups.google.com/d/topic/django-developers/WPGqQ1dGnCQ/discussion
* https://groups.google.com/d/topic/django-developers/1Xj8Zzdokrw/discussion

-- 
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: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

[Mikhail Korobov]

Hi Carl, 

The issue is not only with unique_together indeed. Please correct me if I'm 
wrong, but it seems there is no way currently to use model validation with 
fields dependent on each other when one of these fields is not POSTed 
directly by user. Example:

# models.py
class Ticket(models.Model):
created_by = models.ForeignKey(User, related_name='created_tickets')
responsible = models.ForeignKey(User, related_name='todo')

def clean():
# we don't want to allow tickets where created_by == responsible for 
some reason
from django.core.exceptions import ValidationError
if self.created_by == self.responsible:   
raise ValidationError('Responsible is incorrect.') 

# views.py
class TicketForm(forms.ModelForm):
class Meta:
model = Ticket
exclude = ['created_by']

@login_required
def add_ticket(request):
form = TicketForm(request.POST or None)
if form.is_valid():
ticket = form.save(commit=False)
ticket.created_by = request.user

# todo: handle ticket.full_clean()

ticket.save()
return redirect('ticket_list')
return TemplateResponse(request, 'tickets/add.html', {'form': form})

Model.clean method is always called on form validation (unlike field 
validators that are excluded if field is excluded from form). And we can't 
write validator for 'responsible' field or for 'created_by' field (so that 
it will be excluded from validation on form.is_valid) because this validator 
won't have an access to other model fields. So the only option here seems to 
move validation from model level to form level.

Please consider this use case while rethinking model validation. The 
proposed context manager seems to be a very good idea and I hope it will fix 
this issue as well.

-- 
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: Request for comments: custom admin filters

[Mikhail Korobov]

Hi Julien,

Thanks for working on this!

Will your patch simplify creating filters not based on choices? E.g.
min/max filters where exact minimun and maximum values can be entered
(using form with method=GET and input fields for values)? I want a
pony ;)

It would also be good to make FilterSpec.output using template, not
the hardcoded python.

On 13 апр, 23:11, Jacob Kaplan-Moss  wrote:
> Hi Julien --
>
> Thanks for your work on this! I'm working my way through the patch,
> and it's looking good. I'm pretty happy with the internals, though I
> do have some questions about the public API:
>
> * I'm rather unhappy with the `SimpleListFilter`/`FieldListFilter`
> breakdown, and especially the way `FieldListFilter` is documented.
> This isn't friendly:
>
>     Note that this method is far more complex than simply using a field
>     name or a ``SimpleListFilter`` class, as there currently is no simple
>     way available to manipulate a ``FieldListFilter``. You may, however,
>     find some useful examples with the built-in filters defined in
>     :mod:`django.contrib.admin.filterspecs`.
>
> Ugh.
>
> It seems to me that `FieldListFilter` is something of an internal
> detail required to maintain the existence of a bunch of pre-refactor
> stuff, right? If so, I think I'd like to see `SimpleListFilter`
> renamed to something more obvious (maybe call it `ListFilter` and call
> the parent class `BaseListFilter` or collapse it into a single class).
> Then the docs can explain that a list filter could be a
> `FieldListFilter` but that that API is considered internal and prone
> to change/refactoring. Make sense?
>
> * There's a weird discrepancy (to me) between the signatures of
> `get_choices(self, request)` and `get_query_set(self, changelist,
> queryset)`. I'd expect to have the `request` available to both
> methods, I think, and I don't really know what `changelist` is doing
> there or what I'd use it for. Can you talk a bit about why those
> signatures work that way?
>
> * `def get_title(self): return "size"` seems like overkill -- why not
> just `title="size"`?
>
> Thanks again!
>
> 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: uWSGI documentation

[Mikhail Korobov]

Hi James,

Some notes:

> One of the great advantages of uWSGI_ is its ability to gradually
> restart each worker without loosing any request.

I think mod_wsgi in daemon mode is doing the same.

> Nginx provides the uwsgi module by default these days.

Stock nginx does not provide uwsgi module on latest CentOS, RedHat,
Debian and even on latest released Ubuntu by default. Ubuntu will
update default nginx to 0.8.x soon but on other OS'es 0.7.x or even
0.6.x will remain default for a long time.

> location / {
>uwsgi_pass 127.0.0.1:3000;
># in case of a socket file:
># uwsgi_pass unix:/tmp/yourproject.sock;
>}

According to this: http://www.iana.org/assignments/port-numbers 3000
port "SHOULD NOT be used without IANA registration. The registration
procedure is defined in [RFC4340], Section 19.9." because it is one of
"DCCP Registered ports". I don't know if this is a serious issue but
it seems that it is better to recommend port numbers above 49152 in
tutorials.

Thanks!

On 8 апр, 22:34, is_null  wrote:
> On Apr 4, 3:59 pm, Kristaps Kūlis   wrote:
>
> >   I believe that running manage.py for production deployments is "not
> > way to go", as it has been noted by django devs previously.
> >  What purpose would runuwsgi command serve ?
>
> I'm unsure. Roberto's proposal is interresting: i could configure
> uwsgi in settings.py and then just run runuwsgi. Although that looks a
> little to much for django itself, it would be great in a pluggable
> django app.
>
> That said i'd love to *not* have to put a 3 liners module in my
> project directory anymore. A runuwsgi command might not be the only
> way to solve this need.
>
> On Apr 2, 4:44 pm, Łukasz Rekucki  wrote:
>
>
>
> > +1. More docs didn't hurt anybody. At least while there is someone to
> > maintain them.
>
> You can count on me (until death).
>
>
>
> > > What do you think ?
>
> > My first impression is that you're focusing too much on all those
> > switches. That section got me totally lost. That should be simplified.
> > Also, do I really need to type all that stuff? I probably won't be
> > doing that on production, so showing how to place it in a
> > configuration file would be better.
>
> > I would also drop the whole "advantages" section. The purpose of the
> > page is to show how to deploy a Django app onuWSGI, not compare it
> > against other solutions. You also mention some features, but never
> > show how to enable/use them which is confusing.
>
> Thanks for your feedback, I did my best to take it in consideration
> while rewriting most of the documentation this week.
>
> (Some examples are still missing but most of it is there. Feedback is
> always appreciated)
>
> 
> How to use Django with uWSGI
> 
>
> .. highlight:: bash
>
> uWSGI_ is a fast, self-healing and developer/sysadmin-friendly
> application
> container server coded in pure C.
>
> .. _uWSGI:http://projects.unbit.it/uwsgi/
>
> Prerequisite: uWSGI
> ===
>
> `uWSGI wiki`_ describes
> several
> installation procedures. Using pip, the python package manager,
> installing any
> uWSGI_ version can be done with one command line. For example::
>
>     # install current stable version
>     pip install uwsgi
>     # or install LTS (long term support)
>     pip installhttp://projects.unbit.it/downloads/uwsgi-lts.tar.gz
>
> Prerequisite: general concept
> =
>
> uWSGI model
> ---
>
> uWSGI_ operates on a client-server model. Your Web server (ie. Nginx,
> Apache)
> communicates with a django-uwsgi "worker" process to serve dynamic
> contents.
> The Web server can communicate with the uWSGI_ process either:
>
> * directly by the uWSGI_ protocol through a socket created by uWSGI_,
> * or by proxying HTTP requests to the minimalist HTTP server built in
> uWSGI_,
>
> In the first case: the Web server can do uWSGI_ protocol (often with a
> module). It can then use either a Unix domain socket (a "named pipe"
> on Win32
> systems), or it can use a TCP socket. What you choose is a matterr of
> preference. Usually, a TCP socket is easier because connecting to a
> port
> doesn't require special permissions.
>
> In the second case, the Web server doesn't need to do uWSGI_ protocol.
> It just
> needs to be able to proxy HTTP requests to the HTTP server built-in
> uWSGI_.
> The procedure is the same than proxying any HTTP server. Note that the
> Web
> server is a "reverse proxy" in this case.
>
> Configuring the uWSGI server
> 
>
> In any case, when you set up your Web server, you'll just need to
> point its
> uwsgi or proxy module to the host/port or socket you specified when
> starting
> the uWSGI_ server.
>
> .. admonition:: Choosing the socket
>
>     The easiest is to set the socket to a high level (>1024) local
> port like
>     

Re: Revised form rendering

[Mikhail Korobov]

Hi Carl and Gregor,

On 2 апр, 01:17, Carl Meyer  wrote:
>
> > 3. The designers I worked with are often interested on adding custom css 
> > class
> >    or an attribute to a form field. Most of the time this is really a pain 
> > to
> >    do if you don't have control over the python form code. Imagine a 
> > reusable
> >    app that ships with urls, views, forms. To add a single class you would
> >    need to: (a) overwrite the predefined url because you want (b) to specify
> >    an additional parameter for the view which is (c) your custom subclass of
> >    the thirdparty form::
>
> >        class ChangedAttributeForm(ThirdPartyForm):
> >            field = forms.CharField(max_length=50,
> >                widget=TextInput(attrs={'class': 'fancy-text-input'}))
>
> >    btw: This also violates the DRY principle since you have to redefine the
> >    used field type, it's attributes (like ``max_length=50``) and the widget.
>
> >    I want to tell the designer how he can do this without my help in the
> >    template.
>
> I agree with your Motivations section - in particular this final line,
> which sums up the core motivation as I see it.
>

This goal can be achieved without changing django, see
https://bitbucket.org/kmike/django-widget-tweaks

Each widget is instantiated by field in 'as_widget' method now, and
the field passes 'attrs' argument to widget with extra attributes.

The idea behind django-widget-tweaks is simple: it provides template
filters that take field instance and wrap its 'as_widget' bound method
so it receives extra attributes (and pass these extra attributes to
widget). This way widget attributes (including input types and css
classes) can be altered in templates without touching python, e.g.:

{{ myform.field|add_class:"fancy-text-input" }}
{{ search_form.query|attr:"type:search" }}

Implementation: 
https://bitbucket.org/kmike/django-widget-tweaks/src/0e9bac3c71bd/widget_tweaks/templatetags/widget_tweaks.py

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

dumpdata, json, management commands and utf8

[Mikhail Korobov]

./manage.py dumpdata --format=json
command produces unreadable output for non-ascii symbols now (they are
encoded as \u ).

Such encoding is not required according to http://www.ietf.org/rfc/rfc4627.txt
(section 2.5):

"All Unicode characters may be placed within the quotation marks
except for the characters that must be escaped: quotation mark,
reverse solidus, and the control characters (U+ through U+001F)."

There is a snippet ( http://djangosnippets.org/snippets/2258/ ) with a
quick fix but it is incorrect.

The encoding is performed by django.core.serializers.json.Serializer.
Output is not nice because ensure_ascii argument is not set (and it is
True by default):

def end_serialization(self):
simplejson.dump(self.objects, self.stream,
cls=DjangoJSONEncoder, **self.options)

It seems there is no way to pass additional options to serializer with
existing dumpdata command:

 return serializers.serialize(format, objects, indent=indent,
use_natural_keys=use_natural_keys)

But wait, we can define custom serializers! This is undocumented but
quite easy:

# serializers/pretty_json.py
from django.core.serializers.json import Serializer as JSONSerializer
from django.core.serializers.json import Deserializer as
JSONDeserializer
from django.core.serializers.json import DjangoJSONEncoder
from django.utils import simplejson

class Serializer(JSONSerializer):
def end_serialization(self):
simplejson.dump(self.objects, self.stream,
cls=DjangoJSONEncoder,
ensure_ascii=False, **self.options)

Deserializer = JSONDeserializer

Then it can be added to SERIALIZATION_MODULES (by the way, this option
is not mentioned in serializer docs):
SERIALIZATION_MODULES = {'json-pretty': 'serializers.pretty_json'}.
After that, I expect this to work:

./manage.py dumpdata --format=json-pretty 

But it doesn't work and fails with an UnicodeEncodeError:

Traceback (most recent call last):
  File "./manage.py", line 11, in 
execute_manager(settings)
  File "/Users/kmike/envs/planor/src/django/django/core/management/
__init__.py", line 438, in execute_manager
utility.execute()
  File "/Users/kmike/envs/planor/src/django/django/core/management/
__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/kmike/envs/planor/src/django/django/core/management/
base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
  File "/Users/kmike/envs/planor/src/django/django/core/management/
base.py", line 229, in execute
self.stdout.write(output)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
184-189: ordinal not in range(128)

Management commands write to stdout and python's stdout doesn't
perform any meaningful unicode encoding. Argh.

So self.stdout should be changed to something that understands utf8,
e.g.:

import sys
import codecs
from django.core.management.commands.dumpdata import Command as
Dumpdata

class Command(Dumpdata):
def execute(self, *args, **options):
stdout = options.get('stdout', sys.stdout)
options['stdout'] = codecs.getwriter('utf8')(stdout)
return super(Command, self).execute(*args, **options)

After these changes initial problem is solved.

But I think my adventure reveals something that can be improved in
django itself.

1) It is even mentioned in django docs (
http://docs.djangoproject.com/en/1.2/topics/serialization/#notes-for-specific-serialization-formats
) that "If you're using UTF-8 (or any other non-ASCII encoding) data
with the JSON serializer, you must pass ensure_ascii=False as a
parameter to the serialize() call. Otherwise, the output won't be
encoded correctly."

If I'm understanding properly, with ensure_ascii=True serializer
doesn't work for non-ascii bytestrings and produces ugly output for
unicode strings; with ensure_ascii=False serializer works for all
bytestrings and produces nice output for unicode strings. So why is
ensure_ascii=True default? Setting it to False is technically
backwards-incompatible but I think it is backwards-incompatible in a
good way.

2) If stdout doesn't handle Unicode, wouldn't it be better to wrap
'output' with smart_str or to wrap stdout itself to be utf8-capable by
default? django.core.management.base.BaseCommand.execute wraps data
written to self.stderr with smart_string, but this is not the case for
self.stdout.

After 1) and 2) the initial problem with non-readable fixtures will be
solved automatically without defining custom serializers and hacking
with management commands.

I'm not opening separate issues in bug tracker because they all seems
to be related (dumpdata improvements, serializer improvements,
BaseCommand unicode handling), the changes are not trivial (encodings
can be hard and stdout is often mysterious) and I want to make sure
I'm not missing a point.

-- 
You received this message because you are subscribed to the Google Groups 
"Django 

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Mikhail Korobov]

Just for the record: I'm with Ivan here and think that

from django.template.response import TemplateResponse
def my_view(request):
return TemplateResponse(request, 'foo.html')

is worse than

from django.shortcuts import render
def my_view(request):
return render(request, 'foo.html')

I think that the cases where user should prefer 'render' returning
HttpResponse over 'render' returning TemplateResponse are rare so the
API by itself should suggest TemplateResponse. TemplateResponse is
more flexible and can provide a performance benefit (the template
rendering can be prevented in some cases).

I don't see much value in adding 'render' shortcut that just use
RequestContext after TemplateResponse is introduced - one can still
use render_to_response if TemplateResponse is undesired and one
shouldn't use such 'render' in other cases.

'render' as alias for TemplateResponse seems fine for me: it is a
shortcut and it adds value by simplifying the API.

On 29 ноя, 19:07, Harro  wrote:
> I agree with Jacob on the bake/baked thing.. but maybe it's just
> CakePHP coming to haunt me :S
>
> On Nov 29, 1:09 pm, Ivan Sagalaev  wrote:
>
>
>
>
>
>
>
> > On 11/29/2010 02:58 PM, Russell Keith-Magee wrote:
>
> > > My counterargument would be this -- if you use TemplateResponse,
> > > there's no need to use a shortcut at all.
>
> > Yes, this is what I understood from your reasoning. I'm concerned more
> > with documentation. Namely, what are we going to suggest for usage in
> > the tutorial. The nice short `render()` shortcut lacks the power of
> > TemplateResponse and TemplateResponse is not *that* nice and short.

-- 
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: Changing settings per test

[Mikhail Korobov]

Btw, not all settings can be patched just by overriding values because
some of them are cached and the change of the value doesn't change
django behaviour (e.g. TEMPLATE_CONTEXT_PROCESSORS option behaves like
this).

On 5 ноя, 02:23, Łukasz Rekucki  wrote:
> Funny, I had exactly the same problem today at work while refactoring
> my application's tests suite :).
>
> Currently, I'm using a pair of save/restore functions: save() monkey
> patches the settings module and returns a dictionary of old values,
> restore() puts back the old values based on the dictionary. I usually
> put this in setUp/tearDown so I don't have to repeat in every test. I
> was about to propose that
> Django's TestCase should do something similar by default.
>
> Both the decorator and context processor are very useful, but having
> something to set values for the whole test case instead of a single
> test or a block of code would be great too. I was thinking about
> something in line of:
>
>     class EmailTestCase(TestCase):
>         settings = dict(DEFAULT_FROM_EMAIL="webmas...@example.com")
>
> On 4 November 2010 21:11, David Cramer  wrote:
>
>
>
>
>
> > With a decorator approach here's what I whipped up:
>
> > (This is dry code)
>
> > def with_settings(**overrides):
> >    """Allows you to define settings that are required for this
> > function to work"""
> >    NotDefined = object()
> >    def wrapped(func):
> >       �...@wraps(func)
> >        def _with_settings(*args, **kwargs):
> >            _orig = {}
> >            for k, v in overrides.iteritems():
> >                _orig[k] = getattr(settings, k, NotDefined)
>
> >            try:
> >                func(*args, **kwargs)
> >            finally:
> >                for k, v in _orig.iteritems():
> >                    if v is NotDefined:
> >                        delattr(settings, k)
> >                    else:
> >                        setattr(settings, k, v)
> >        return _with_settings
> >    return wrapped
>
> > I'm not familiar with the context managers, but I imagine those would
> > solve things like adjusting CONTEXT_PROCESSORS.
>
> > On Thu, Nov 4, 2010 at 1:06 PM, Dan Fairs  wrote:
>
> >>> Let me start with an example test:
>
> >>> def test_with_awesome_setting(self):
> >>>    _orig = getattr(settings, 'AWESOME', None)
> >>>    settings.AWESOME = True
>
> >>>    # do my test
> >>>    ...
>
> >>>    settings.AWESOME = _orig
>
> >> Pedant: there's a small bug above which has bitten me before doing a 
> >> similar thing - settings.AWESOME  ends up set to None after the test has 
> >> run if it didn't exist before.
>
> >>> Anyways, I'd love to hear how others have dealt with this and any
> >>> other possible solutions.
>
> >> I've used Michael Foord's Mock library to patch a setting for the duration 
> >> of a test case. Chris Withers' testfixtures library also has some sugar to 
> >> provide a context manager approach, though I haven't used that in a little 
> >> while.
>
> >> Cheers,
> >> Dan
>
> >> --
> >> Dan Fairs | dan.fa...@gmail.com |www.fezconsulting.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-develop...@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-develop...@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.
>
> --
> Łukasz Rekucki

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

I'm quite busy now and don't think I'll be able to make the patch
ready by 1.3 alpha 1.

On 2 ноя, 20:06, Mikhail Korobov <kmik...@googlemail.com> wrote:
> Hi all.
>
> The new patch is attached to ticket 
> (seehttp://code.djangoproject.com/attachment/ticket/12816/render_shortcut...
> ). Docs are cumbersome (and incomplete), and a couple of middleware
> tests are missing.
>
> 1) Template response middleware is introduced. It is applied only for
> response instances that can be baked.
> 2) Exception is raised on content access or iteration for unbaked
> response.
> 3) 'force_bake' method is removed. 'bake' now behaves like old
> 'force_bake'.
> 4) Test client fixes are no longer needed and they are removed.
> 5) Some docs are added.
>
> Am we in hurry to get 'render' shortcut into 1.3 alpha 1 or it can be
> added later?
>
> On 31 окт, 00:49, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
>
>
>
> > On 10/30/2010 10:47 PM, SmileyChris wrote:
>
> > > It seems a simple enough proposal that trying to access the content
> > > property would raise an error until it is explicitly baked. Problem
> > > solved.
>
> > True. I seem to somehow missed it between the lines. Thanks! I'm +1 on
> > it by the way.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi all.

The new patch is attached to ticket (see
http://code.djangoproject.com/attachment/ticket/12816/render_shortcut.6.diff?format=raw
). Docs are cumbersome (and incomplete), and a couple of middleware
tests are missing.

1) Template response middleware is introduced. It is applied only for
response instances that can be baked.
2) Exception is raised on content access or iteration for unbaked
response.
3) 'force_bake' method is removed. 'bake' now behaves like old
'force_bake'.
4) Test client fixes are no longer needed and they are removed.
5) Some docs are added.

Am we in hurry to get 'render' shortcut into 1.3 alpha 1 or it can be
added later?

On 31 окт, 00:49, Ivan Sagalaev  wrote:
> On 10/30/2010 10:47 PM, SmileyChris wrote:
>
> > It seems a simple enough proposal that trying to access the content
> > property would raise an error until it is explicitly baked. Problem
> > solved.
>
> True. I seem to somehow missed it between the lines. Thanks! I'm +1 on
> it by the way.

-- 
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: contrib.staticfiles app concerns

[Mikhail Korobov]

Hi Waldemar,

The problem was really hard to understand for me because I was
assuming you're trying to describe django.contrib.staticfiles flaw
while you were describing the problem with third-party asset managers.

I think you have described a real problem here but (as you said) this
problem is not a problem of Django itself and should be reported to
asset apps authors and users via bug tracker and blog posts, not to
django-developers list. I don't see how the incompatibility you
describe relates to staticfiles at all - it is a flaw in asset
managers and it is related to how css/html works, not to the way
django works.


On 30 окт, 15:36, Waldemar Kornewald  wrote:
> On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss  
> wrote:
> > There's no way I'm adding text like that to the staticfiles
> > documentation. Not in a million years. It's confusing to me, and
> > *I've* been following this discussion. Can you imagine how confusing
> > that's going to be to people who *haven't*? The vast majority of users
> > aren't going to know what the heck an "asset manager" is, what this
> > "standards-complient" business is, or why they should care. They're
> > reading this document because they want to get a CSS file up onto a
> > production server somewhere. That's it.
>
> Why do you think was the patch named "ridiculous-patch.diff"? I'm
> trying to communicate the *problem* because you haven't understood
> that, yet. But for some reason you expect me to send the *solution*
> (that's why you ask for a patch). That makes no sense at all because
> you don't know what the *problem* is.
>
> > As far as I can understand from the vast reams you've written so far,
> > what you're basically saying is "if you use url() in a CSS file it
> > needs to point to an URL that actually exists." I'm pretty sure most
> > people are smart enough to figure that out.
>
> No, you're looking at this from the wrong perspective. When people use
> django.contrib.staticfiles then of course they will use URLs that
> exist. Anything else is ridiculous. Why would anyone write URLs that
> don't work? :)
>
> But is it so difficult to understand that a lot of developers use some
> *other* asset manager? More than 70% of those other asset managers
> *force* you to write *broken* URLs. Most asset managers are broken!
> The problem is not staticfiles, but the large number of broken
> 3rd-party asset managers.
>
> Why are they broken? Because they combine your files and once your
> files are combined the URLs suddenly work. IOW, those asset managers
> convert *broken* URLs into *working* URLs. That's their convention and
> their standard. Is this stupid? Yes. It's still reality. A very large
> number of developers use this stupid broken convention.
>
> Now what do you think, how likely is it that open-source developers
> will use such a *broken* asset manager (not staticfiles) and release
> *broken* CSS code that is *incompatible* with
> django.contrib.staticfiles? It's far too likely for Django to ignore
> this.
>
> This is the last time I try to explain this. As you said, let's just
> wait for the first users to report a bug. I hope that then you'll
> realize that Django's *3rd-party* asset managers have to be fixed, not
> staticfiles.
>
> I'll do my part and at least convert django-mediagenerator to a
> staticfiles-compatible URL scheme.
>
> Bye,
> Waldemar
>
> --
> Django on App Engine, MongoDB, ...? Browser-side Python? It's 
> open-source:http://www.allbuttonspressed.com/blog/django

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

On 29 окт, 10:09, Russell Keith-Magee  wrote:
>
> Ah - I wasn't aware there was a working implementation of this idea --
> did I miss a link somewhere?
>

No, there is no full working implementation. I'm talking about Ivan's
code snippet:

 response = get_response(...)
 if hastattr(response, 'force_bake'):
 # apply template response middleware
 response.force_bake()
 # apply normal response middleware

===

> If any template-response-middleware were to bake the
> response, subsequent template-reposnse-middlewares could potentially
> have problems, as any changes they make to context etc will be
> ignored.

Just realized that this is not correct. Changes won't be ignored but
the template will be rendered twice.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi Russel,

Thank you for your reviews and moving things on!

On 29 окт, 07:35, Russell Keith-Magee  wrote:
>
> I like this idea -- it's is an elegant solution to the problem, and
> avoids all the backwards compatibility issues I can think of.
>
> I have two comments:
>
> Firstly, there needs to be a shortcut for non-template responses. If
> your response isn't a template response, there's no point putting it
> through Template Reponse Middleware.
>

Ivan's code doesn't put non-template responses through template
response middleware. Whenever the response is a template response is
determined by the presence of 'force_bake' method.

> Secondly, it seems to me like there may be some need for baking
> protection here. If any template-response-middleware were to bake the
> response, subsequent template-reposnse-middlewares could potentially
> have problems, as any changes they make to context etc will be
> ignored. Wouldn't it make sense to put a flag on the TemplateResponse
> that prohibits accidental baking? That way the force_bake() that
> happens between the template-response-middleware and the normal
> response-middleware would be the guaranteed point at which the
> template is writ large as content.
>

As I can see, users shouldn't bake responses not only in middlewares.
They shouldn't bake responses anywhere in their code.

The original TemplateResponse idea was not the same.

Original TemplateResponse was baked on first content access. Now
TemplateResponse should be baked exactly in one place: right after
template response middlewares. Other baking points seems to be error-
prone with this solution.

So maybe it will be better not to make bake/force_bake public so that
users won't be able to shoot themselves in the foot? And maybe it'll
be better even not to bake response magically on first content
access?

> Regarding #9886 and #14523 -- they're both RFC, and they're on my todo
> list of things to commit in the near future. I just need to find a few
> spare moments to give the patches a final review and commit.
>
> Yours,
> Russ Magee %-)

That's great!

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

On 28 окт, 12:55, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
> On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
>
> > 1. 'Border' middleware is a backwards-compatible change, the
> > requirement to bake response in middleware isn't.
>
> > The
> > difference is only that you propose to execute 'bake' in the end of
> > response cycle and I propose to execute it at the beginning of the
> > response cycle but to make this customizable (by changing the position
> > of the BakingMiddleware).
>
> I understand your points now, thanks. Two things bother me about
> 'border' middleware:
>
> - its semantics is a bit different than that of others middleware in the
> list in settings and this difference is not explicitly clear when
> looking at the list
>
> - it's bad to have a boilerplate code that people just have to put somewhere
>
> I've spent a night with a thought and now I think I can propose even
> better solution.
>
> We can introduce a new kind of middleware -- "template response
> middleware" for lack of a better name. A user who wants to do something
> with a template response *before* it is baked has to write a middleware
> like this:
>
>  class ContextInjectionMiddleware:
>  def process_template_response(self, request, response):
>  # do something with response
>
> Request handling code would look like this then:
>
>  response = get_response(...)
>
>  if hastattr(response, 'force_bake'):
>  # apply template response middleware
>  response.force_bake()
>
>  # apply normal response middleware
>
> This way we:
>
> - are getting rid of force_bake in HttpResponse where it's a noop
> - maintain backward compatibility since response is baked before all
> currently written middleware
> - require explicitly named method to deal with a new concept
>
> What's not to like? :-)

I like your solution.

The request handling code have to be put into WSGIHandler and into
ModPythonHandler so I'll wait until the patch for 
http://code.djangoproject.com/ticket/9886
will be landed.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hmm, and now I don's see a use case for the 'force_bake' (and maybe
even public 'bake' method) method if BakingMiddleware is implemented.
With BakingMiddleware there is exactly one place where response should
be baked and user's code shouldn't be calling 'force_bake' and even
'bake' on responses.

On 27 окт, 19:55, Mikhail Korobov <kmik...@googlemail.com> wrote:
> Hi Ivan,
>
> Let me explain why I prefer 'border' middleware way (that is
> implemented) over explicit baking in messages middleware (that was
> implemented but then replaced with 'border' middleware).
>
> 1. 'Border' middleware is a backwards-compatible change, the
> requirement to bake response in middleware isn't.
>
> 2. With BakingMiddleware it is clear what middlewares expect responses
> to be baked and what expect responses to be unbaked. This provides
> practical benefits. If there is no BakingMiddleware and some
> middleware wants to change template or context it must call
> 'force_bake' (not just 'bake') to make sure the changes will apply. If
> there is an another middleware that want to change something (template
> or context) then template will be rendered several times. With
> BakingMiddleware the contract is a bit different. Template will be
> rendered exactly 1 time in this case because middleware can assume
> that the response was not baked.
>
> 3. The code behind BakingMiddleware should be executed anyway in order
> to prevent template rendering outside try-catch statements. The
> difference is only that you propose to execute 'bake' in the end of
> response cycle and I propose to execute it at the beginning of the
> response cycle but to make this customizable (by changing the position
> of the BakingMiddleware).
>
> On 27 окт, 13:33, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
>
>
>
> > On 10/25/2010 04:33 PM, Russell Keith-Magee wrote:
>
> > >   * The problem with messages is a big one -- probably even a
> > > show-stopper if we can't find a way to reconcile the general use case
> > > that it represents (i.e., we don't just need a fix for
> > > contrib.messages  -- we need to explain how/why the problem exists,
> > > and provide a consistent approach for analogous problems)
>
> > I apologize in advance if I missed some important bits of the
> > conversation I'm on vacation right now :-).
>
> > Why can't we teach messages middleware to just explicitly bake a
> > response and call it a proper solution? By adding `force_bake` to the
> > HttpResponse class itself we effectively declare that *any* HttpResponse
> > can be lazy and middleware that expects some side-effects from a
> > response has to bake it.
>
> > Sure it must be documented that middleware forcing response baking
> > should work after the ones that don't.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi Ivan,

Let me explain why I prefer 'border' middleware way (that is
implemented) over explicit baking in messages middleware (that was
implemented but then replaced with 'border' middleware).

1. 'Border' middleware is a backwards-compatible change, the
requirement to bake response in middleware isn't.

2. With BakingMiddleware it is clear what middlewares expect responses
to be baked and what expect responses to be unbaked. This provides
practical benefits. If there is no BakingMiddleware and some
middleware wants to change template or context it must call
'force_bake' (not just 'bake') to make sure the changes will apply. If
there is an another middleware that want to change something (template
or context) then template will be rendered several times. With
BakingMiddleware the contract is a bit different. Template will be
rendered exactly 1 time in this case because middleware can assume
that the response was not baked.

3. The code behind BakingMiddleware should be executed anyway in order
to prevent template rendering outside try-catch statements. The
difference is only that you propose to execute 'bake' in the end of
response cycle and I propose to execute it at the beginning of the
response cycle but to make this customizable (by changing the position
of the BakingMiddleware).

On 27 окт, 13:33, Ivan Sagalaev  wrote:
> On 10/25/2010 04:33 PM, Russell Keith-Magee wrote:
>
> >   * The problem with messages is a big one -- probably even a
> > show-stopper if we can't find a way to reconcile the general use case
> > that it represents (i.e., we don't just need a fix for
> > contrib.messages  -- we need to explain how/why the problem exists,
> > and provide a consistent approach for analogous problems)
>
> I apologize in advance if I missed some important bits of the
> conversation I'm on vacation right now :-).
>
> Why can't we teach messages middleware to just explicitly bake a
> response and call it a proper solution? By adding `force_bake` to the
> HttpResponse class itself we effectively declare that *any* HttpResponse
> can be lazy and middleware that expects some side-effects from a
> response has to bake it.
>
> Sure it must be documented that middleware forcing response baking
> should work after the ones that don't.

-- 
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: contrib.staticfiles app concerns

[Mikhail Korobov]

Why isn't it fine to have different URL rewriting schemes for
different assets bundlers?

E.g. if one uses django-compress he should list all files he wants to
combine in settings.py and then output them into template as {%
compressed_css 'my_css' %}. If one is using django-compressor then he
list all files he want to combine in template inside some other other
template tag. Then django-compress and django-compressor combine
files, store combined variants somewhere and provide correct urls for
stored files.

Why should one care if these files are stored and prepared the same
way in django-mediagenerator, django-compress and django-compressor or
not? Why should django.contrib.staticfiles care about this? There are
a lot of bundling apps now and they all already provide different
answers for this problem.

Please excuse me if I don't understand some obvious but I can't see a
point. As I can see, the purpose of django.contrib.staticfiles is to
collect media files from reusable applications in one place so that
developers of reusable application can rely on it and don't require
users to manually copy and update files from app source releases. It
also solves a problem of media files customizing - where to put
customized media files so that they can survive app upgrade. And
that's all. Why do you see django.contrib.staticfiles as a framework
for css/js combiners?

On 27 окт, 17:38, Waldemar Kornewald <wkornew...@gmail.com> wrote:
> Hi Mikhail,
>
>
>
>
>
> On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov <kmik...@googlemail.com> 
> wrote:
> > Hi Waldemar,
>
> > Could you explain why is this should belong to django staticfiles app?
> > This app has nothing to do with combining css files. It has one view
> > (django.contrib.staticfiles.views.serve) in order to serve files in
> > development. This is only a helper view used in development and I
> > don't see why it is necessary to support css-combining solutions in
> > it. If some app combines/compresses css/js files it should handle the
> > path rewriting etc. and provide a way to insert the media into
> > templates (e.g. via templatetag as django-compress do) because all
> > these stuff can be handled in different ways.
> > django.contrib.staticfiles (and it's serve view) doesn't stand in the
> > way here and I think it's the best it could do. If
> > django.contrib.staticfiles prevents something to be implemented then
> > it's an another story and this should be fixed.
>
> While it's true that staticfiles doesn't handle CSS-combining, many
> people will want to combine their files and thus use a different asset
> manager (potentially building on top of staticfiles; doesn't matter).
> If staticfiles doesn't set a standard here then different apps will
> depend on different (incompatible) URL rewriting schemes and this is
> bad for reusability. Staticfiles is supposed to prevent this. So, we
> need a standard here. Depending on which standard we choose it can
> have an influence on staticfiles and in order to be compliant with the
> standard we might have to rewrite URLs in staticfiles, too.
>
> Bye,
> Waldemar
>
> --
> Django on App Engine, MongoDB, ...? Browser-side Python? It's 
> open-source:http://www.allbuttonspressed.com/blog/django

-- 
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: contrib.staticfiles app concerns

[Mikhail Korobov]

Hi Waldemar,

Could you explain why is this should belong to django staticfiles app?
This app has nothing to do with combining css files. It has one view
(django.contrib.staticfiles.views.serve) in order to serve files in
development. This is only a helper view used in development and I
don't see why it is necessary to support css-combining solutions in
it. If some app combines/compresses css/js files it should handle the
path rewriting etc. and provide a way to insert the media into
templates (e.g. via templatetag as django-compress do) because all
these stuff can be handled in different ways.
django.contrib.staticfiles (and it's serve view) doesn't stand in the
way here and I think it's the best it could do. If
django.contrib.staticfiles prevents something to be implemented then
it's an another story and this should be fixed.

On 27 окт, 16:24, Waldemar Kornewald  wrote:
> On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald
>
>
>
>
>
>  wrote:
> > OK, I just went through django-mediagenerator to check if there's
> > anything else needed by staticfiles and I noticed that we need to have
> > a standard for URLs in CSS files (e.g., url(image.png)).
>
> > Since we don't know the STATICFILES_URL in our CSS code we have to use
> > relative paths when referencing images. When CSS files get combined
> > the resulting file is often in a different folder than its source
> > files. This will break relative paths. Now we have these solutions:
> > 1. keep URLs untouched when combining
> > 2. rewrite URLs relative to source files
> > 3. rewrite URLs relative to the combined file's path
> > 4. rewrite URLs relative to STATICFILES_URL
>
> > URL rewriting would convert relative paths to absolute URLs beginning
> > with STATICFILES_URL.
>
> > (1) is the easiest solution and it might be used by very simple asset
> > managers. This approach is also used by quite a few CSS and JS
> > frameworks (e.g. jQuery UI). Disadvantage: It only works if the
> > combined CSS file is in the same location as its source files.
>
> > (2) is very intuitive because it behaves exactly like with uncombined
> > files. Disadvantage: URL rewriting is inconsistent if you also support
> > CSS compilers like Sass because the URLs used in imported files would
> > be relative to the master file. This means imported files have to make
> > assumptions about the master file's location which is very confusing
> > and bad for reusability.
>
> > (3) is too confusing and makes too many assumptions about the combined
> > file's location which is confusing and bad for reusability.
>
> > (4) is the most consistent solution. No matter whether you use a CSS
> > compiler or normal CSS files or something else, URLs always behave the
> > same. Disadvantage: At first you might expect different behavior, so
> > it's quite not as intuitive as (2), but it's very easy to understand
> > once you know what it does. Also, it doesn't have any of the
> > disadvantages of (2).
>
> > IMHO, (4) is the best solution because it's consistent. (2) is the
> > second best solution. It should be easy to adapt the code in
> > django-mediagenerator and make a little patch for staticfiles, so it
> > behaves like (4). What do you think?
>
> > In any case, staticfiles would need to rewrite URLs in its view, too.
> > Otherwise we can't provide a consistent solution across all asset
> > managers.
>
> Since this is pretty important and it would be great to have in the
> alpha release, what do you need to be able to make a good decision,
> here?
>
> Bye,
> Waldemar

-- 
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: It is real to add ticket #8054 to 1.3 milestone?

[Mikhail Korobov]

Hi Alex and Yuri,

To make it clear: is this only a syntax change and all other benefits
can be achieved with current implementation?

The benefits from the wiki:

1. ability to customize and localize 3rd-party application without
fork it - it is as easy with current ModelAdmin. ModelAdmin looks up
it's own methods so 'get_bar_column' in wiki can be put into
AccountAdmin.

2. ability to apply custom template filters on field value or model
method returned value without any magic - it is also possible:
template filters are just functions and @register.filter decorator
doesn't harm them.

3. ability to specify witch field will be used in order for column
based on model method - this is also totally possible with current
implementation

4. beautifully API to admin change list customization - as I can see
it is the only benefit here

Am I correct and the goal is only to change list_display syntax?


On 27 окт, 10:58, "burc...@gmail.com"  wrote:
> Hi Alex,
>
> Patch is looking good, except few small things.
> Wiki docs are also very good, but they are quite incomplete.
> Replied to the ticket.
>
>
>
>
>
> On Tue, Oct 26, 2010 at 11:23 PM, Alex Kamedov  wrote:
> > Can anybody rewiew the patch?
>
> > On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov  wrote:
>
> >> Hi All,
> >> I uploaded patch with tests and little improvements
>
> >>http://code.djangoproject.com/attachment/ticket/8054/8054-list-column...
> >> I think it ready for review.
> >> I really sorry, but I couldn't write good documentation because English
> >> isn't my own language. The maximum of my possibility in writing docs is
> >> here http://code.djangoproject.com/wiki/ListColumns   For more examples see
> >> folder admin_listcolumn in regression tests provided by last my patch.
> >> Cheers,
> >> Alex Kamedov
> >> On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley  wrote:
>
> >>> Hi alekam,
>
> >>> This is certainly the kind of ticket that we want to deal with in 1.3
> >>> since it's been around so long and deferred a couple times. Starting
> >>> the discussion here is definitely the right way to make it happen.
>
> >>> That said, at the very least it needs a thorough code review, a full
> >>> set of tests, and good documentation before it can be included.
>
> >>> I'm not personally sold on the way the functionality is implemented,
> >>> but I'd have to think on what would be preferable. I'm sure others
> >>> will have stronger opinions on it one way or the other.
>
> >>> All the best,
>
> >>>    - Gabriel
>
> >>> On Oct 12, 9:47 am, alekam  wrote:
> >>> > Hi All,
>
> >>> > I found very useful ticket #8054. This ticket has accepted status and
> >>> > assigned to brosher about 2 years. The problem describes on ticket
> >>> > detail page and in the
> >>> > wikihttp://code.djangoproject.com/wiki/ListColumns
> >>> > The ticket has patch witch passes all existing regression tests and I
> >>> > plan to write unit tests for it.
> >>> > It is real to add ticket #8054 to 1.3 milestone?
>
> >>> > Cheers,
>
> >>> > Alex Kamedov
>
> >>> --
> >>> 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.
>
> > --
> > 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.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.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-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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

I propose the following solution for middleware problem:

1. Introduce the BakingMiddleware
(django.template.response.BakingMiddleware or
django.template.middleware.BakingMiddleware?). This middleware bakes
the response using .bake() method.
2. Put this middleware as last middleware in default settings.py (with
a blank line above).
3. The ugly bit: if there is no BakingMiddleware in
settings.MIDDLEWARE_CLASSES then assume that it is the last
middleware.
django.core.handlers.base.BaseHandler should be patched for that.
Warning may also be emitted if there is no explicit BakingMiddleware
in settings.py so that this ugly bit can be removed in future.
4. raise ImproperlyConfigured exception if unbaked response is
received by messages middleware

This way changes will be backwards-compatible on middleware level
because middlewares will only receive baked responses by default. No
existing middlewares make use of TemplateResponse and things will work
as usual with default setup.

Cool new response middlewares that makes use of TemplateResponse (e.g.
do some caching or paginating on context objects) can be put after the
BakingMiddleware so they will be able mess with an unbaked response if
it is available.

Implementation (no tests and docs): 
http://bitbucket.org/kmike/django/changeset/68571aa0e5a3

On 25 окт, 20:36, Mikhail Korobov <kmik...@googlemail.com> wrote:
> contrib.messages middleware was broken because it relies on something
> that should happen on template rendering (iteration over the messages
> in this case) and don't access response content directly.
>
> I was about to introduce 'BakingMiddleware' - the middleware that
> bakes the response explicitly. It can be a border between middlewares
> with rendered templates as requirement and middlewares without this
> requirement. But we can't inject this middleware in backwards-
> compatible way to user's code so I just fixed the contrib.messages
> middleware. I still like the idea but don't know if we can afford 'add
> BakingMiddleware before the MessagesMiddleware' note in upgrade docs.
>
> This is all quite similar to problems django have with streaming http
> responses 
> (seehttp://groups.google.com/group/django-developers/browse_thread/thread...)
> and maybe there are some ideas from that thread which may be useful.
>
> On 25 окт, 19:33, Russell Keith-Magee <russ...@keith-magee.com> wrote:
>
>
>
> > 2010/10/25 Mikhail Korobov <kmik...@googlemail.com>:
>
> > > Sorry for massive email spam on this list :)
>
> > > I came up with even more naive implementation of
> > > TemplateResponseMixin:http://bitbucket.org/kmike/django/src/a3e242ca7b4b/django/views/gener...
>
> > > response.template_name will contain a list of names and there is
> > > (almost) no code duplication between TemplateResponse and
> > > TemplateResponseMixin with this implementation. Custom template
> > > loading and context instantiation go to TemplateResponse subclasses.
>
> > This is starting to look good to me; here are some comments, going
> > back a couple of messages:
>
> >  * Yes, you've got the right idea with regards to the role played by
> > the various TemplateResponseMixin methods
>
> >  * It seems reasonable to me that assertTemplateUsed would require
> > some baking, and yes, that should be happening at the test client
> > before template rendering signals are disconnected.
>
> >  * The problem with messages is a big one -- probably even a
> > show-stopper if we can't find a way to reconcile the general use case
> > that it represents (i.e., we don't just need a fix for
> > contrib.messages  -- we need to explain how/why the problem exists,
> > and provide a consistent approach for analogous problems)
>
> >  * Following the convention of the rest of the API, the call to
> > get_template_names() should be internal to get_response(), not passed
> > in as an argument.
>
> >  * I'm not entirely convinced that get_response() is needed now. As
> > your implementation currently stands, render_to_response() is just a
> > call to get_response() -- which suggests that the extra level of
> > indirection isn't needed.
>
> > Backing up this position -- most of the flexibility that
> > TemplateResponseMixin has is to enable the easy integration of
> > different rendering engines and contexts; those API points are now
> > provided by TemplateResponse, so there isn't any need to preserve them
> > in the mixin. If you want to use a different loader, template
> > renderer, context instance, etc, you subclass TemplateResponse.
>
> > So - revised source code:
>
> > class TemplateResponseMixin(object):
> >     """
> >  

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

contrib.messages middleware was broken because it relies on something
that should happen on template rendering (iteration over the messages
in this case) and don't access response content directly.

I was about to introduce 'BakingMiddleware' - the middleware that
bakes the response explicitly. It can be a border between middlewares
with rendered templates as requirement and middlewares without this
requirement. But we can't inject this middleware in backwards-
compatible way to user's code so I just fixed the contrib.messages
middleware. I still like the idea but don't know if we can afford 'add
BakingMiddleware before the MessagesMiddleware' note in upgrade docs.

This is all quite similar to problems django have with streaming http
responses (see
http://groups.google.com/group/django-developers/browse_thread/thread/9dc1bb93eed77987/c61c1b8d5426c1cb?lnk=gst=http+content#c61c1b8d5426c1cb)
and maybe there are some ideas from that thread which may be useful.

On 25 окт, 19:33, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> 2010/10/25 Mikhail Korobov <kmik...@googlemail.com>:
>
> > Sorry for massive email spam on this list :)
>
> > I came up with even more naive implementation of
> > TemplateResponseMixin:http://bitbucket.org/kmike/django/src/a3e242ca7b4b/django/views/gener...
>
> > response.template_name will contain a list of names and there is
> > (almost) no code duplication between TemplateResponse and
> > TemplateResponseMixin with this implementation. Custom template
> > loading and context instantiation go to TemplateResponse subclasses.
>
> This is starting to look good to me; here are some comments, going
> back a couple of messages:
>
>  * Yes, you've got the right idea with regards to the role played by
> the various TemplateResponseMixin methods
>
>  * It seems reasonable to me that assertTemplateUsed would require
> some baking, and yes, that should be happening at the test client
> before template rendering signals are disconnected.
>
>  * The problem with messages is a big one -- probably even a
> show-stopper if we can't find a way to reconcile the general use case
> that it represents (i.e., we don't just need a fix for
> contrib.messages  -- we need to explain how/why the problem exists,
> and provide a consistent approach for analogous problems)
>
>  * Following the convention of the rest of the API, the call to
> get_template_names() should be internal to get_response(), not passed
> in as an argument.
>
>  * I'm not entirely convinced that get_response() is needed now. As
> your implementation currently stands, render_to_response() is just a
> call to get_response() -- which suggests that the extra level of
> indirection isn't needed.
>
> Backing up this position -- most of the flexibility that
> TemplateResponseMixin has is to enable the easy integration of
> different rendering engines and contexts; those API points are now
> provided by TemplateResponse, so there isn't any need to preserve them
> in the mixin. If you want to use a different loader, template
> renderer, context instance, etc, you subclass TemplateResponse.
>
> So - revised source code:
>
> class TemplateResponseMixin(object):
>     """
>     A mixin that can be used to render a template.
>     """
>     template_name = None
>     template_response_class = TemplateResponse
>
>     def render_to_response(self, context):
>         """
>         Returns a response with a template rendered with the given context.
>         """
>         return self.template_response_class(
>             request=self.request,
>             template=self.get_template_names(),
>             context=context,
>             **response_kwargs
>         )
>
>     def get_template_names(self):
>         """
>         Returns a list of template names to be used for the request. Must 
> return
>         a list. May not be called if render_to_response is overridden.
>         """
>         if self.template_name is None:
>             return []
>         else:
>             return [self.template_name]
>
> However, all this is a moot point if we can't find a fix for the
> contrib.messages problem.
>
> 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-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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Sorry for massive email spam on this list :)

I came up with even more naive implementation of
TemplateResponseMixin: 
http://bitbucket.org/kmike/django/src/a3e242ca7b4b/django/views/generic/base.py#cl-87

response.template_name will contain a list of names and there is
(almost) no code duplication between TemplateResponse and
TemplateResponseMixin with this implementation. Custom template
loading and context instantiation go to TemplateResponse subclasses.

On 24 окт, 17:32, Mikhail Korobov <kmik...@googlemail.com> wrote:
> new changes (integration with generic views, test client and messages
> middleware fixes):http://bitbucket.org/kmike/django/overview
>
> Yet another gotchas:
>
> - response.template_name for generic views will contain Template
> instance, not template names, so response.template_name is quite
> misleading. The better name ('template') is already taken by test
> client (but it is deprecated in 1.3). I can't find a good solution so
> leave the 'template_name' for now.
>
> - hasattr(response, 'bake') and callable(response.bake) checks are
> ugly. The alternative is to provide HttpResponse.bake method but this
> way HttpResponse will be aware of TemplateResponse and it doesn't seem
> clean for me.
>
> On 24 окт, 02:14, Mikhail Korobov <kmik...@googlemail.com> wrote:
>
>
>
> > Yes, you're right and I was wrong, the messages middleware doesn't
> > return response as-is. I'll take a look.
>
> > As for tests, response.context and response.templates are not
> > available for TemplateResponse instances before they are baked so test
> > client should be patched to explicitly bake the response. There is
> > response.template_context and response.template_name but their
> > semantics differ.
>
> > On 24 окт, 01:52, SmileyChris <smileych...@gmail.com> wrote:
>
> > > The points were just off the top of my head from memory, when I get
> > > back to work I'll have a look to see what the actual cases are.
>
> > > Regarding the messages middleware, I *know* there's a problem. A
> > > message won't be marked as "read", since the template hasn't iterated
> > > the messages object by the time the middleware is triggered
>
> > > On Oct 23, 8:35 am, Mikhail Korobov <kmik...@googlemail.com> wrote:
>
> > > > Hi Chris,
>
> > > > I don't see anything harmful neither in
> > > > django.contrib.messages.middleware.MessageMiddleware nor in
> > > > django.test.testcases.assertContains.
> > > > Messages middleware passes response as-is and assertContains reads
> > > > 'content' attribute and thus forces the baking.
>
> > > > at lest the following test case forks fine for me:
>
> > > > class AssertTestCase(TestCase):
> > > >     def test_assert_contains(self):
> > > >         request = RequestFactory().get('/')
> > > >         template = Template('foo')
> > > >         response = TemplateResponse(request, template)
> > > >         self.assertContains(response, 'oo')
>
> > > > Can you please provide more details?
>
> > > > On 23 окт, 00:21, SmileyChris <smileych...@gmail.com> wrote:
>
> > > > > In my use of TemplateResponse in a real project, we encountered two
> > > > > gotchas that I can think of off the top of my head:
>
> > > > > 1. You need to explicitly bake the response if you are testing using
> > > > > assertContains
> > > > > 2. You need to explicitly bake the response before the
> > > > > contrib.messages middleware
>
> > > > > On Oct 23, 1:32 am, Russell Keith-Magee <russ...@keith-magee.com>
> > > > > wrote:
>
> > > > > > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov 
> > > > > > <kmik...@googlemail.com> wrote:
> > > > > > > Russell's comments were helpful in discovering the edge case.
> > > > > > > _set_content behaves differently for baked and non-baked 
> > > > > > > responses:
>
> > > > > > > response = render(request, Template('foo'))
> > > > > > > response.content = 'bar'
> > > > > > > print response.content    # 'foo'
> > > > > > > response.content = 'baz'
> > > > > > > print response.content    # 'baz'
>
> > > > > > > This is confusing so I think responses should be marked as baked 
> > > > > > > in
> > > > > > > _set_content, not in force_bake.
>
> > > > > 

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

new changes (integration with generic views, test client and messages
middleware fixes): http://bitbucket.org/kmike/django/overview

Yet another gotchas:

- response.template_name for generic views will contain Template
instance, not template names, so response.template_name is quite
misleading. The better name ('template') is already taken by test
client (but it is deprecated in 1.3). I can't find a good solution so
leave the 'template_name' for now.

- hasattr(response, 'bake') and callable(response.bake) checks are
ugly. The alternative is to provide HttpResponse.bake method but this
way HttpResponse will be aware of TemplateResponse and it doesn't seem
clean for me.

On 24 окт, 02:14, Mikhail Korobov <kmik...@googlemail.com> wrote:
> Yes, you're right and I was wrong, the messages middleware doesn't
> return response as-is. I'll take a look.
>
> As for tests, response.context and response.templates are not
> available for TemplateResponse instances before they are baked so test
> client should be patched to explicitly bake the response. There is
> response.template_context and response.template_name but their
> semantics differ.
>
> On 24 окт, 01:52, SmileyChris <smileych...@gmail.com> wrote:
>
>
>
> > The points were just off the top of my head from memory, when I get
> > back to work I'll have a look to see what the actual cases are.
>
> > Regarding the messages middleware, I *know* there's a problem. A
> > message won't be marked as "read", since the template hasn't iterated
> > the messages object by the time the middleware is triggered
>
> > On Oct 23, 8:35 am, Mikhail Korobov <kmik...@googlemail.com> wrote:
>
> > > Hi Chris,
>
> > > I don't see anything harmful neither in
> > > django.contrib.messages.middleware.MessageMiddleware nor in
> > > django.test.testcases.assertContains.
> > > Messages middleware passes response as-is and assertContains reads
> > > 'content' attribute and thus forces the baking.
>
> > > at lest the following test case forks fine for me:
>
> > > class AssertTestCase(TestCase):
> > >     def test_assert_contains(self):
> > >         request = RequestFactory().get('/')
> > >         template = Template('foo')
> > >         response = TemplateResponse(request, template)
> > >         self.assertContains(response, 'oo')
>
> > > Can you please provide more details?
>
> > > On 23 окт, 00:21, SmileyChris <smileych...@gmail.com> wrote:
>
> > > > In my use of TemplateResponse in a real project, we encountered two
> > > > gotchas that I can think of off the top of my head:
>
> > > > 1. You need to explicitly bake the response if you are testing using
> > > > assertContains
> > > > 2. You need to explicitly bake the response before the
> > > > contrib.messages middleware
>
> > > > On Oct 23, 1:32 am, Russell Keith-Magee <russ...@keith-magee.com>
> > > > wrote:
>
> > > > > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov 
> > > > > <kmik...@googlemail.com> wrote:
> > > > > > Russell's comments were helpful in discovering the edge case.
> > > > > > _set_content behaves differently for baked and non-baked responses:
>
> > > > > > response = render(request, Template('foo'))
> > > > > > response.content = 'bar'
> > > > > > print response.content    # 'foo'
> > > > > > response.content = 'baz'
> > > > > > print response.content    # 'baz'
>
> > > > > > This is confusing so I think responses should be marked as baked in
> > > > > > _set_content, not in force_bake.
>
> > > > > > The patch that should resolve this concern and Russell's concerns
> > > > > > regarding the 
> > > > > > tests:http://bitbucket.org/kmike/django/changeset/00f8be464749
>
> > > > > > I'll take a look at docs and generic views integration later.
>
> > > > > > Should new generic views return TemplateResponse by default?
>
> > > > > I would have thought so. Is there a compelling reason why CBV's
> > > > > shouldn't return a TemplateResponse?
>
> > > > > 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-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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Yes, you're right and I was wrong, the messages middleware doesn't
return response as-is. I'll take a look.

As for tests, response.context and response.templates are not
available for TemplateResponse instances before they are baked so test
client should be patched to explicitly bake the response. There is
response.template_context and response.template_name but their
semantics differ.


On 24 окт, 01:52, SmileyChris <smileych...@gmail.com> wrote:
> The points were just off the top of my head from memory, when I get
> back to work I'll have a look to see what the actual cases are.
>
> Regarding the messages middleware, I *know* there's a problem. A
> message won't be marked as "read", since the template hasn't iterated
> the messages object by the time the middleware is triggered
>
> On Oct 23, 8:35 am, Mikhail Korobov <kmik...@googlemail.com> wrote:
>
>
>
> > Hi Chris,
>
> > I don't see anything harmful neither in
> > django.contrib.messages.middleware.MessageMiddleware nor in
> > django.test.testcases.assertContains.
> > Messages middleware passes response as-is and assertContains reads
> > 'content' attribute and thus forces the baking.
>
> > at lest the following test case forks fine for me:
>
> > class AssertTestCase(TestCase):
> >     def test_assert_contains(self):
> >         request = RequestFactory().get('/')
> >         template = Template('foo')
> >         response = TemplateResponse(request, template)
> >         self.assertContains(response, 'oo')
>
> > Can you please provide more details?
>
> > On 23 окт, 00:21, SmileyChris <smileych...@gmail.com> wrote:
>
> > > In my use of TemplateResponse in a real project, we encountered two
> > > gotchas that I can think of off the top of my head:
>
> > > 1. You need to explicitly bake the response if you are testing using
> > > assertContains
> > > 2. You need to explicitly bake the response before the
> > > contrib.messages middleware
>
> > > On Oct 23, 1:32 am, Russell Keith-Magee <russ...@keith-magee.com>
> > > wrote:
>
> > > > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov 
> > > > <kmik...@googlemail.com> wrote:
> > > > > Russell's comments were helpful in discovering the edge case.
> > > > > _set_content behaves differently for baked and non-baked responses:
>
> > > > > response = render(request, Template('foo'))
> > > > > response.content = 'bar'
> > > > > print response.content    # 'foo'
> > > > > response.content = 'baz'
> > > > > print response.content    # 'baz'
>
> > > > > This is confusing so I think responses should be marked as baked in
> > > > > _set_content, not in force_bake.
>
> > > > > The patch that should resolve this concern and Russell's concerns
> > > > > regarding the 
> > > > > tests:http://bitbucket.org/kmike/django/changeset/00f8be464749
>
> > > > > I'll take a look at docs and generic views integration later.
>
> > > > > Should new generic views return TemplateResponse by default?
>
> > > > I would have thought so. Is there a compelling reason why CBV's
> > > > shouldn't return a TemplateResponse?
>
> > > > 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-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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi all again!

I've done some research on generic views integration and think that
TemplateResponseMixin should be refactored in order to use
TemplateResponse (SimpleTemplateResponse actually) because it
currently assumes that template must be rendered before the response
is returned.

'render_template' hook doesn't fit lazy-rendered responses and
'get_response' == 'render_to_response' if there is no
'render_template' hook. I propose to eliminate 'get_response' and
'render_template' hooks. These hooks are not used by django itself.

get_response's purpose was to make it easy to override response class.
Because render_to_response now returns response itself it is natural
to override render_to_response instead of get_response.

render_template's purpose was to change a way template is rendered. I
don't know what is the exact use case. If one wants to use e.g. jinja2
template engine then he should override get_template method so it will
return jinja.Template instead of django.Template (both have a 'render'
method).

Am I understand their purposes properly?

Anyway, one can override render_to_response hook and return any
HttpResponse subclass using any template rendering logic.

Here is a chart to make things clear:
http://www.lucidchart.com/publicSegments/view/4cc313b1-9478-4985-9870-2a190afcbe04

Some other gotchas:
- TemplateResponseMixin.render_to_response should possibly be renamed
to 'TemplateResponseMixin.render' for consistency.
- django.test.TestCase.assertTemplateUsed should possibly bake the
response explicitly because TemplateResponses are lazy.

I need core developers' blessing.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

On 22 окт, 18:10, Łukasz Rekucki  wrote:
> On 22 October 2010 03:59, Russell Keith-Magee  wrote:
> > 2010/10/21 Łukasz Rekucki :
> >> Both render_to_response() and direct_to_template() have one very
> >> annoying flaw:http://code.djangoproject.com/ticket/12669. Please add
> >> a "response_class" keyword to your render() function ;). Thanks!
>
> > Is this addressed by the status_code argument to TemplateResponse? i.e.,
>
> > return TemplateResponse(request, template, context, status_code=403)
>
> > We could also include some constants to make things a little prettier:
>
> > return TemplateResponse(request, template, context, status_code=FORBIDDEN)
>
> > Would that satisfy your use case for #12669?
>
> Yes, it does, but constants are a must have, imho.
>

I think we shouldn't include constants in django itself because they
are already available:

>>> import httplib
>>> httplib.FORBIDDEN
403

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi Chris,

I don't see anything harmful neither in
django.contrib.messages.middleware.MessageMiddleware nor in
django.test.testcases.assertContains.
Messages middleware passes response as-is and assertContains reads
'content' attribute and thus forces the baking.

at lest the following test case forks fine for me:

class AssertTestCase(TestCase):
def test_assert_contains(self):
request = RequestFactory().get('/')
template = Template('foo')
response = TemplateResponse(request, template)
self.assertContains(response, 'oo')

Can you please provide more details?

On 23 окт, 00:21, SmileyChris <smileych...@gmail.com> wrote:
> In my use of TemplateResponse in a real project, we encountered two
> gotchas that I can think of off the top of my head:
>
> 1. You need to explicitly bake the response if you are testing using
> assertContains
> 2. You need to explicitly bake the response before the
> contrib.messages middleware
>
> On Oct 23, 1:32 am, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>
>
>
> > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov <kmik...@googlemail.com> 
> > wrote:
> > > Russell's comments were helpful in discovering the edge case.
> > > _set_content behaves differently for baked and non-baked responses:
>
> > > response = render(request, Template('foo'))
> > > response.content = 'bar'
> > > print response.content    # 'foo'
> > > response.content = 'baz'
> > > print response.content    # 'baz'
>
> > > This is confusing so I think responses should be marked as baked in
> > > _set_content, not in force_bake.
>
> > > The patch that should resolve this concern and Russell's concerns
> > > regarding the 
> > > tests:http://bitbucket.org/kmike/django/changeset/00f8be464749
>
> > > I'll take a look at docs and generic views integration later.
>
> > > Should new generic views return TemplateResponse by default?
>
> > I would have thought so. Is there a compelling reason why CBV's
> > shouldn't return a TemplateResponse?
>
> > 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-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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Patch is ready for review: 
http://bitbucket.org/kmike/django/changeset/37d977574923

This is the TempleteResponse by Simon Willison with tests and minor
tweaks.

Notes:

- TemplateResponse and SimpleTemplateResponse reside in
django.template.response
- django/shortcuts/__init__.py used to have extra spaces. They are
removed.
- *args and **kwargs in TemplateResponse and SimpleTemplateResponse
are gone in order to provide more help for IDEs
- 'content' argument is not allowed for TemplateResponse and
SimpleTemplateResponse now
- context can be omitted now, the only required argument for
SimpleTemplateResponse is the template; request and template are
required for TemplateResponse
- 'response_class' is not implemented but the status code can be
passed as 'status' parameter.
- _set_content doesn't return a value now

The result:

from django.shortcuts import render

def my_view(request):
render(request, 'foo.json', {'foo': 'bar'}, 'application/json',
504)

def extended_view(request)
response = my_view(request)
response.template_context.update({'foo': 'spam', 'baz': 'egg'})
response.template_name = 'spam.json'
response.status_code = 400
return response



On 21 окт, 23:56, Mikhail Korobov <kmik...@googlemail.com> wrote:
> I love programming: two-liner shortcut turns to be a massive core
> refactoring ;) Ivan, thank you for the research.
>
> I'll provide a draft patch for 'render == TemplateResponse' soon.
>
> By the way, Łukasz Rekucki's suggestion to add the 'response_class' to
> render shortcut is complicated much by TemplateResponse because
> SimpleTemplateResponse is inherited from HttpResponse.
>
> On 21 окт, 22:34, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
>
>
>
> > On 10/21/2010 03:22 PM, Ivan Sagalaev wrote:
>
> > > On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
> > >> 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
> > >> issue resolved?
>
> > > I'll look into it this evening (MSD).
>
> > So I did.
>
> > There are actually two problems:
>
> > - Exceptions in response middleware are indeed happen outside of the
> > request's `try .. except` block. This is a problem by itself[1] and I'd
> > be happy to fix it after ticket 9886[2] is committed. It's another
> > refactoring of core request code so I don't want to mess things up doing
> > one patch on top of another :-).
>
> > - Non-pretty plain text tracebacks can be caused not only be middleware
> > but also by any error occurring during template rendering. Because all
> > this happen *after* request was returned to the web server handler and
> > is being iterated over.
>
> > This second problem can be easily fixed by introducing a method for
> > explicit evaluation of the content: `evaluate()` or `force_content()`
> > that will be a noop for any HttpRespone class except the
> > TemplateResponse. The method will be called by the request handler right
> > before returning the response.
>
> > Sounds good?
>
> > P.S. BTW looking at the TemplateResponse implementation I see that Simon
> > had actually intended it to be effectively *the* render shortcut[3]. I
> > find it quite beautiful really :-)
>
> > [1]:http://code.djangoproject.com/ticket/14523
> > [2]:http://code.djangoproject.com/ticket/9886
> > [3]:http://github.com/simonw/django-openid/blob/master/django_openid/resp...

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Well, I don't mean that now we all must write only class-based views.
I was talking about reusable views and most views don't have to be
reusable (though it would be nice). Django now can help developer in
writing reusable views and it was not the case when TemplateResponse
was invented. That's what I mean with "TemplateResponse is less useful
now". TemplateResponse and class-based views are targeting the same
problem and they are different ways to solve it. I don't know what is
better, the argument was that we already have one way to reuse view
logic.

My statement about "only complicate things in django 1.3" was
premature, sorry. TemplateResponse is indeed a nice way to reuse view
logic that don't require writing a class-based view.

The ticket in DDN is http://code.djangoproject.com/ticket/12815.

So now the questions are:

1. Do we need 2 nice ways for reusing view logic (with and without
classes)? I don't have an opinion on this.
2. Does TemplateResponse allow pretty exception pages or not? Is Ben's
issue resolved?


On 21 окт, 13:25, Ivan Sagalaev  wrote:
> On 10/21/2010 11:10 AM, James Bennett wrote:
>
>
>
>
>
> > Django cares about whether your views meet the following criteria:
>
> > 1. Is a callable object.
> > 2. When called, accepts an instance of HttpRequest as its first
> > positional argument.
> > 3. When called, returns an instance of HttpResponse or raises an exception.
>
> > That's it. Write them as functions, if that makes sense for your use
> > case. Write them as classes with callable instances, if that makes
> > sense for your use case. Generic views are now class-based because
> > that's what seems to work best *for the case of generic views*;
> > subclassing and overriding is, for the type of flexibility the generic
> > views need, simpler and cleaner than supporting long lists of keyword
> > arguments. But the generic views are not all views, and not all views
> > have to do what the generic views do. So my position is that you
> > should think about what you need from your view, and choose
> > class-based or function-based as appropriate.
>
> Thanks, that what I thought.
>
> Going back to the argument about TemplateResponse I can say that it's a
> good way for a view-as-function to keep its response hackable.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi Ivan!

On 21 окт, 03:00, Ivan Sagalaev  wrote:
>
> Wait!!!
>
> Sorry… Hello everyone :-)
>
> If I remember correctly TemplateResponse was solving a problem of some
> middleware wanting to mess with a view context before it's baked into
> final string representation. This would solve in a good way what now is
> accomplished by things like @render_to decorator.
>
> What I don't understand from your reasoning is how class-based views are
> going to help here? From what I see only Django-supplied generic views
> are now class-based and we didn't deprecate simple user view functions.
> Which means that "render" won't be as useful for them if it wouldn't
> provide any means to post-process the context and if the context won't
> be aware of request: these are two main points why people are not happy
> with render_to_response right now.
>

I see this as several separate specific problems / use cases.

1. Developer writes a view and want to reuse it (e.g. change the
context).

My assumptions was:
a) Class based views are now the recommended way to write reusable
views
b) The main benefit from TemplateResponse is the ability to reuse view
responses. I made this assumption because of the example in #12815,
the 'this pattern would be particularly valuable for customising the
admin' statement and the original example in your proposal (
http://groups.google.com/group/django-developers/msg/d5df254f01800ee2
).
c) b) can now be achieved by writing a class-based view

2. Developer wants to write a middleware that messes with view
context. Class-based views are not going to help here. But I thought
it is not nearly as demanded as the first use case. This is useful but
not mandatory. That's where my reasoning came from.

> Mikhail, do you have any actual objections against TemplateResponse or
> you just don't want to complicate your implementation? If it is the
> latter then TemplateResponse has been already implemented[1] by Simon
> Willison. You might just use it.
>
> [1]:http://github.com/simonw/django-openid/blob/master/django_openid/resp...

Thanks for pointing out the implemented TemplateResponse. No, I
haven't actual objections against it and just don't want to complicate
the implementation. There was an issue with TemplateResponse approach
for Ben Firshman ( 
http://groups.google.com/group/django-developers/msg/fc9e0f8810d3e784
) and the ticket is in DDN so it is not as simple as just replace
HttpResponse with TemplateResponse.

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

I think the correct ticket is http://code.djangoproject.com/ticket/9081
and it is in 'almost-wontfix' state now. Yes, it's a great time to
either move it to wontfix or mark as accepted and implement alongside
with the render shortcut.

On 21 окт, 02:05, Łukasz Rekucki <lreku...@gmail.com> wrote:
> On 20 October 2010 21:57, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
>
>
>
>
> > 2010/10/20 Mikhail Korobov <kmik...@googlemail.com>:
> >> There is an unresolved question in the ticket: "The only hesitation is
> >> the relationship with #12815; we should resolve that decision before
> >> committing anything for this ticket."
>
> >> #12815 is about introducing TemplateResponse. Is the patch with
> >> 'render' shortcut returning just HttpResponse acceptable? I think that
> >> TemplateResponse is less useful after class-based views make their way
> >> into trunk so 'render' shortcut shouldn't bother returning
> >> TemplateResponse. There are ways to reuse view logic (and change view
> >> context in particular) now and TemplateResponse (which was a good
> >> addition to django 1.2/1.1/1.0) seems to only complicate things in
> >> django 1.3.
>
> > I agree completely with this reasoning - just render returning an
> > HttpResponse is fine, I think.
>
> Both render_to_response() and direct_to_template() have one very
> annoying flaw:http://code.djangoproject.com/ticket/12669. Please add
> a "response_class" keyword to your render() function ;). Thanks!
>
> --
> Łukasz Rekucki

-- 
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: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

That's great! I'll mark the ticket as assigned for me then.

There is an unresolved question in the ticket: "The only hesitation is
the relationship with #12815; we should resolve that decision before
committing anything for this ticket."

#12815 is about introducing TemplateResponse. Is the patch with
'render' shortcut returning just HttpResponse acceptable? I think that
TemplateResponse is less useful after class-based views make their way
into trunk so 'render' shortcut shouldn't bother returning
TemplateResponse. There are ways to reuse view logic (and change view
context in particular) now and TemplateResponse (which was a good
addition to django 1.2/1.1/1.0) seems to only complicate things in
django 1.3.

On 21 окт, 01:02, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Wed, Oct 20, 2010 at 1:48 PM, Mikhail Korobov <kmik...@googlemail.com> 
> wrote:
> > So please add the 'render' shortcut in 1.3.
>
> It's one of the things on my list. If you'd like to make it happen
> faster, a patch + tests would make it a no-brainer for me.
>
> 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-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.

Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

Hi all,

I'm talking about this ticket: http://code.djangoproject.com/ticket/12816

With class-based views landed and the deprecation of
django.views.generic.simple (and direct_to_template in particular)
there won't be simple and undeprecated shortcut for
render_to_response.

So please add the 'render' shortcut in 1.3. direct_to_template was
always a hack (when used as render_to_response replacement) because it
'unrolls' callables and 1.3 seems to be a perfect place to replace
small hacks for proper solutions.

Please take my proposal as a gentle reminder :) If there are reasons
for this not to be in 1.3 (developer time, unresolved questions, etc.)
then fine, but it'll be pity if this feature won't be in next release
just because we forget about it.

-- 
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: Ticket #5416 -- assertNumQueries

[Mikhail Korobov]

Hi all,

If it will be a contextmanager then it can also be extended to perform
like a decorator: http://gist.github.com/573536
I think this can be useful.

On 11 окт, 04:17, Alex Gaynor  wrote:
> Hey all,
>
> I've been spending some time with ticket #5416[0], which is a request
> for assertNumQueries in tests.  The primary objection Russ had to the
> previous patch in this vein was that It uses connection.queries as
> opposed to the proposed signal.  However, Russ and I spoke last night
> and neither of us had a compelling argument for a signal in favor of
> connection.queries and the new logging behavior.  The one sticking
> point is the use of settings.DEBUG, however we don't want to pollute
> the default SQL query path with extra debugging, and the reality is
> everyone's ad-hoc implementations of this use it anyways.  The other
> discussion we had was whether to also offer this function as a
> contextmanager.  This presents a compelling API, and though we
> wouldn't be able to use it in Django itself we could still provide it,
> the only issue is that it'd be difficult to properly test (the best
> way would probably be a test which uses exec).  Any feedback on either
> of these issues would be appreciated.
>
> Alex
>
> PS: I also converted our test suite to use these and though it's
> slightly more verbose in some situations (where we want to make
> assertions about the return value), it's a net reduction in code due
> to removing the ad-hoc implementations every test has.
>
> 0:http://code.djangoproject.com/ticket/5416
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

-- 
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: No caching if request.GET not empty

[Mikhail Korobov]

Hi Thomas,

there is a ticket for that:

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


On 29 сен, 16:36, Thomas Guettler  wrote:
> Hi,
>
> I got not response on django-users, now I ask here:
>
> requests with a query string (http://example.com?foo=bar) are not cached in 
> Django:
>
> http://code.djangoproject.com/browser/django/trunk/django/middleware/...
> {{{
>         if not request.method in ('GET', 'HEAD') or request.GET:
>             request._cache_update_cache = False
>             return None # Don't bother checking the cache.
>
> }}}
>
> If the query string would be used in _generate_cache_key() (utils/cache.py),
> requests with a not empty request.GET could be cached.
>
> I see no reason, not to cache requests with a query string.
>
> Can someone explain this?
>
> I read the documentation[1], but couldn't find a hint way GET requests
> with a query string are not cached.
>
> Should I open a ticket?
>
> [1] cache docs:http://docs.djangoproject.com/en/dev/topics/cache/
>
>   Thomas
>
> --
> Thomas Guettler,http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de

-- 
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: Why this feature is still not accepted ?

[Mikhail Korobov]

Hi all.  I'm not a django core developer but have some thoughts about
provided patch.

1. The patch is for django 1.1 and django 1.2 have jQuery available so
some parts may be simplified.
2. Some 'var' declarations are missing (check
'dismissChangeCurrentPopup' method and 'i' variable, 'href' and
'element' variables in 'showChangeCurrentPopup' function). This will
pollute global namespace and can cause weird bugs in future.
3. I don't understand some code: what is 'element =
document.getElementById(element_id);' declaration for in
'showChangeCurrentPopup' function (and 'elem =
document.getElementById(toId);' in 'dismissChangeCurrentPopup').
4. Permissions are not checked. It should be mentioned that Django 1.2
now has row permissions foundation.

Regards,
Mikhail.

On 7 авг, 00:46, "dharmesh.patel.eif...@gmail.com"
 wrote:
> Hello,
>
> http://code.djangoproject.com/ticket/11397
>
> As I already implemented it for Django version1.1 but still there is
> no action or feedback on it.

-- 
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: Project-wide cache prefix (low-level API)

[Mikhail Korobov]

This is a good feature and I also have my custom cache backend with
project-level key prefixes. It was easy to implement and doesn't
require changes in django core. But if this backend is in django core
(that's a good idea) then some other changes should be done. There
will be 2 similar options after this change:
CACHE_MIDDLEWARE_KEY_PREFIX and PROJECT_CACHE_PREFIX. I think the
patch should deprecate CACHE_MIDDLEWARE_KEY_PREFIX and maybe overhaul
key_prefix arguments (and their defaults) to make the code cleaner.

On Jun 19, 4:46 am, Byron  wrote:
> Opened a ticket and added my patch..http://code.djangoproject.com/ticket/13795
>
> On Jun 15, 7:15 pm, Giuseppe Ciotta  wrote:
>
>
>
> > On Wed, Jun 16, 2010 at 1:04 AM, Giuseppe Ciotta  wrote:
> > > On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck  wrote:
> > >> On Sun, Jun 13, 2010 at 7:18 AM, lenz  wrote:
> > >>> Could you share your code with us?
> > >>> Thanks you!
>
> > >> This might help:
> > >>http://gist.github.com/425403
>
> > > I have some similar code here:http://gist.github.com/439868
>
> > > It might be better because it wraps an arbitrary cache backend adding
> > > prefix handling, it's not limited to memcache.
>
> > Uhm,http://gist.github.com/425403doesindeed support an arbitrary
> > backend, there's just a call to _get_memcache_timeout() which should
> > be changed in order to make it completely backend agnostic. I left
> > "*args, **kwargs" signatures everywhere to avoid dealing with
> > parameters.

-- 
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: django bugfix releases

[Mikhail Korobov]

So you're aware of this, great! Sorry for mailing list noise then.

On May 26, 1:32 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, May 26, 2010 at 8:22 AM, Mikhail Korobov <kmik...@googlemail.com> 
> wrote:
> > I want to raise the question about stable django micro-releases.
>
> > 1.1 - July 2009,
> > 1.1.1 - October 2009 (released because of security bug),
> > 1.1.2 - May 2010
>
> You're not the first person to notice this, and I agree that this is a
> long time between releases. In our defense, the 1.1.X branch didn't
> actually see much activity until very late in the 1.2 development
> cycle (because the focus on new 1.2 features). If we had cut a 1.1.2
> in January, there actually wouldn't have been very much new in the
> release -- in fact, unless the release was cut after January 28
> (r12344) there wouldn't have been anything especially compelling in
> the 1.1.2 release -- it would have been a release mostly for the sake
> of a release and bumping version numbers.
>
> That said, r12344 was a very important fix, and the long delay in
> releasing 1.1.2 wasn't ideal. The delay was mostly caused by us being
> overoptimistic about the time required for the final bug squashing
> effort, and a lack of awareness about how important the r12344 bugfix
> was until late in the process. We will try to do better handling this
> sort of problem in the future.
>
> 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-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.

django bugfix releases

[Mikhail Korobov]

I want to raise the question about stable django micro-releases.

1.1 - July 2009,
1.1.1 - October 2009 (released because of security bug),
1.1.2 - May 2010

So if some abstract developer want to use stable django release and
follow all the instructions in docs he can get the half-year outdated
django with a number of known bugs that are already fixed in svn.
Please also consider what happen with the csrf_token template tag: it
is in 1.1.2 to ease the migration to 1.2 but 1.1.2 is released
alongside with 1.2 and not before 1.2. The most logical time for 1.2-
preparing 1.1.2 release could be a feature freeze for 1.2 (months
before the 1.2 release).

I think the releases of stable micro-releases should happen more often
for 1.2. You guys are doing great job and it is not good to hide it
from developers.

This is also can be solved with a bit of documentation. If the release
process is time-consuming and is a waste of developers' time then
there is an another way: add the suggestion to use stable svn branch
somewhere in docs. This may be obvious for somebody that there is a
stable django branch in the svn but I'm sure there are a lot of
developers who don't know 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: Django's testing infrastructure

[Mikhail Korobov]

That's great news, thanks!

A very minor issue: web server returns 'Content-Type:text/
html;charset=ISO-8859-1' header for this page: 
http://hudson.djangoproject.com/monitor/?
but the actual page encoding is utf-8 so there are strange symbols
instead of translated strings.

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