Re: Logging config tries too hard

[Ivan Sagalaev]

>
> Just to be sure, which version of Django are you using? There were some 
> simplifications in Django 1.9 that attempted to make writing custom logging 
> configurations easier and further changes in Django 1.10.
>

I'm using 1.9, but I'm referring to the code in master. 
 

>
> https://github.com/django/django/commit/8efea1b8d5b5fb0cfef1a3244c339cebf8af36c5
>
> https://github.com/django/django/commit/5b94b17feff15a9f0345f92fc0568bfe7038e3a3
>

I don't see how these have anything to do with what I'm describing. I'm 
talking about this function: 
https://github.com/django/django/blob/master/django/utils/log.py#L66

When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally 
initializes logging with the hard-coded configuration and then applies a 
user one, if present. And the latter can't really neutralize the effect of 
the former.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6878a75-1e12-4430-86e8-4c5d71ca0972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging config tries too hard

[Ivan Sagalaev]

>
> It’s unclear to me as well how the current system is intended to be used.
>

I can speculate, that the idea was that you *can* disable the existing 
loggers and define your own, but the effect of it actually disabling all 
logging from Django instead of it falling through to the custom root logger 
was overlooked. 

All my projects do this:
>
> # Configure logging manually to avoid merging with Django's defaults.
>
> LOGGING = {
> # custom logging configuration goes here
> }
>
> logging.config.dictConfig(LOGGING)
>
> LOGGING_CONFIG = None
>
> Yes, that's the workaround I'm using right now, too. It works, but it's 
not very clean with having to import logging and do this non-obvious dance 
for what feels like it should just be the default behavior. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a9bf595c-ef52-46df-baee-2c5056c992c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Logging config tries too hard

[Ivan Sagalaev]

Hello everyone,

It's been a while since I last posted here, please forgive if I break any 
new rules inadvertently.

I'd like to revisit a decision made in [18993][]. My use case is very 
simple and obvious: I want all logging going into stdout.

As currently implemented, I can't do it easily with a custom `LOGGING` 
setting, because:

- If I leave existing Django loggers enabled it ties me to the behavior 
chosen by Django, which doesn't necessarily match what I want. For example, 
Django won't log debug and info messages if `DEBUG = False`. And with 
`DEBUG = True` I will be having two log messages for every log into the 
'django' logger: one from the Django's own handler, and another after it 
propagates to my root logger.

- If I disable existing Django loggers, I effectively disable all logging 
from Django (and from 'py.warnings' for good measure).

In fact, the idea of providing a default logging configuration which a user 
can then *build upon* isn't really workable with Python logging: you can 
either fully reuse or fully discard what's been provided, but you can't 
meaningfully define a consistent configuration. Also, I have my doubts that 
this "build upon" use case is based on any real demand. In my experience 
there are only two approaches to configuring logging: "logging? huh, didn't 
think about it" and "get your hands off my logging, I know what I'm doing!"

The latter, incidentally, is what the old way was doing: define a sensible 
default value for `LOGGING` and let users to overwrite it completely. 
Currently, the default logging configuration is hard-coded in 
`django.utils.log`.

Also, I couldn't find the actual reasoning for the current behavior in the 
original ticket. It starts talking about having a more useful default, not 
about changing the way how this default configuration is applied.

[18993]: https://code.djangoproject.com/ticket/18993

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57ca68fd-214a-4fe4-b759-7fc8cb597b35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: __getattr__ on SimpleTemplateResponse causes problems

[Ivan Sagalaev]

Though the patch in the ticket does solve the problem I completely agree 
with removing the code altogether… I'm not a fan of "helpfully" 
reformulating exceptions while trying to be more specific. In practice it 
hurts more than it helps, and this case is just another confirmation.

-- 
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/-/eBeGdoHEgE8J.
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: new backports policy

[Ivan Sagalaev]

On 04/19/2011 02:35 PM, Daniel Moisset wrote:

I'm using 1.3 in production and there's a bugfix I really want, so I
do the backport (and write the code, tests, docs). If I submit this to
the issue tracker, is there a chance my patch will get into the next
minor release, or you won't even consider it?


Even with an accepted (or even ready-for-checkin) ticket containing all 
what's needed committers have some non-trivial amount of work to do. As 
I understand intention of the new policy it's this work that they want 
to decrease.


In such situation at my company we just patch our internal Django 
package. In fact we often patch an immediate problem locally first and 
only then bring the patch to discussion upstream. Much less pressure for 
everyone. I think you should either live with official stable releases 
or be ready to maintain your own if you choose to live on trunk.


--
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: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

On 04/18/2011 02:59 PM, Carl Meyer wrote:

Hmm. Why does it make sense for OneToOneField lookups to behave
differently from *_set managers? If I've got a default manager that
hides "deleted" objects, for instance: why should deleted objects by
default "not exist" when I traverse a reverse FK, but "exist" when I
traverse a OneToOneField?


OK, may be not reverse OneToOne… What I mean is that although it seems 
natural to treat all relations equally they are actually used for 
different use cases where different defaults make sense. For example:


- Reverse many-to-one (topic.article_set) access is used to access a 
(limited) list of children which is expected to behave as any other list 
of such objects and hence should use the default manager.


- Direct one-to-one or many-to-one (article.topic or profile.user) 
access is used to access a parent object and in most real cases it 
doesn't make sense if it's absent for example. Usually you're just 
dealing with a "deleted" child accessing its "deleted" parent which is 
OK. In this case it makes sense to use a pure manager to build the relation.


As for reverse one-to-one I'm really not sure because I can't recall any 
real example to lay upon. Speaking about documentation simplicity (which 
directly influences sanity of its readers) it can be made as simple as 
that:


- pure manager is used whenever there is a clear child-parent realation 
(direct OneToOne and ForeignKey access)

- all other relations use default managers
- explicit use_for_related_fields overrides default behavior

What do you think?

--
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: Accidental logging disabling

[Ivan Sagalaev]

On 04/18/2011 08:25 AM, Carl Meyer wrote:

FWIW, I don't think changing settings in general to be non-lazy is an
option - it will suddenly make a bunch of parts of Django dependent on
DJANGO_SETTINGS_MODULE at import time, where currently they only require
it at runtime (and even then perhaps only when certain functionality is
used).

I do, however, think that it would be fine to have the setup_environ
function explicitly trigger settings-loading. This should never be a
problem, because setup_environ already sets DJANGO_SETTINGS_MODULE. It's
also not an invasive change at all - it should be a one-liner, I think.


After some thinking I agree with you.


That might be reasonable as well - I'm interested to hear Russell speak
to that


Ditto.

--
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: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

On 04/18/2011 11:45 AM, Johannes Dollinger wrote:

I'd vote for (C).
Deprecate `use_for_related_fields` and always use the default manager for 
related managers. Then add the possibility to specify custom mangers for 
individual relations:

  ForeignKey(Foo, related_manager=RSpecialManager)
  ManyToManyField(Foo, manager=SpecialManger, related_manager= 
RSpecialManager)


I like this one too! Except for the "always use the default manager" 
part which, as Carl noted elsewhere in the thread, is not how it works 
right now. Different relation lookups use different defaults. But your 
idea expresses this even better.


--
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: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

On 04/18/2011 11:16 AM, Carl Meyer wrote:

By "just this" I presume you actually mean just the second half of what
you quoted ("explicitly set to False")? In other words, you're proposing
to make use_for_related_fields work as advertised, but make it default
to True instead of False?


Not exactly… I mean that when use_for_related_fields is set explicitly 
Django should respect it. Right now, as I understand from your first 
mail, it doesn't work as False when set to False. So I agree that this 
should definitely be fixed.


What I was saying is that when this attribute is not set current 
behavior does make sense:


- use default manager as a base for *_set managers
- use pure manager as a base for OneToOne and parent lookups

However it can't be described with neither "False by default" nor "True 
by default". I think it's fine and we could just thoroughly document 
this behavior.


P.S. Sorry for being sloppy with my first reply…

--
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: #14891, a.k.a. "related managers don't work how we claim they do"

[Ivan Sagalaev]

On 04/16/2011 04:30 PM, Carl Meyer wrote:

in general, related-object access for
reverse-FKs and M2Ms, contrary to the documentation, will _always_ use
your default manager (actually, a dynamic subclass of it)


It kind of makes sense. You don't want your deleted items to appear in 
results just because you conveniently get a queryset from a related 
manager. In other words, `topic.article_set.all()` should always yield 
the same data as `Article.objects.filter(topic=topic)`.


But I would agree that in this case:


even if "use_for_related_fields" is absent or explicitly set to
False on your Manager subclass.


… the default manager should not be used as a base class. Fixing just 
this would be the best option because it retains current behavior by 
default while allowing other uses if needed.


--
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: Accidental logging disabling

[Ivan Sagalaev]

On 04/15/2011 02:20 AM, akaariai wrote:

I have been using setup_environ in my projects, and the lazy
initialization in can cause some weird problems, for example if you do
manual timing using:
start = datetime.now()
access settings
print 'Used %s' % (datetime.now() - start)

You might get weird results as accessing settings can change your
timezone. Would it be wise that setup_environ() would access the
settings so that they are no more lazy? Or does this cause other
problems?


I didn't have in mind changing the settings object to be non-lazy. It 
looks like a rather intrusive change. And I can't really predict 
consequences. My gut feeling tells me that changing things from being 
immediate to be lazy is the source of many hidden problems. But it 
should be safe vice versa because if the environment already works with 
a lazy object it couldn't count on the order of execution. So immediate 
instantiation shouldn't break the logic. What it could do though is 
affect performance…


Anyway I still think strongly suggesting not disabling existing loggers 
would suffice.


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

Accidental logging disabling

[Ivan Sagalaev]

Hello everyone!

I've found a (may be minor) bug with logging and I'm not sure how it can 
be fixed. Here's a stripped-down example showing the problem:


The settings.py simply configures a single root logger:

DEBUG = True
DATABASES = {
'default': {
'engine': 'django.db.backends.sqlite3', 'name': ':memory:',
},
}

LOGGING = {
'version': 1,
'handlers': {
'default': {'class': 'logging.StreamHandler'},
},
'loggers': {
'': {'handlers': ['default']},
},
}

Then there's a script that initializes settings, does some tests and 
tries to log a message into the 'django.request' logger:


import logging

import settings
from django.core.management import setup_environ
setup_environ(settings)

from django.test.client import RequestFactory

factory = RequestFactory()
factory.get('/')
logger = logging.getLogger('django.request')
logger.error('Error')

The message doesn't show up in the console. Here's what's happening here:

1. setup_environ creates a lazy setting object

2. importing RequestFactory triggers import of django.core.handlers.wsgi 
that creates a logger 'django.request'


3. after some time settings object is accessed for the first time and 
gets initialized


4. while initializing logging dictConfig disables all existing loggers 
including 'django.request'


5. messages being sent into a disabled logger are ignored (even though 
there is an enabled root logger)


In my opinion the main problem here is that dictConfig disables existing 
loggers *by default*. A logger is nothing more than a declaration of a 
name under which a particular set of messages can be distinguished, it 
doesn't bear any actual functionality. Disabling it basically means that 
we disable logging altogether for whoever happened to declare it 
earlier. I suspect there are cases where it might be useful but doing it 
by default doesn't make sense to me.


However this is not what Django is in a position to fix because it's 
what Python's now-standard logging does. What we could fix though is the 
example in the logging documentation:


LOGGING = {
'version': 1,
'disable_existing_loggers': True,
...

Explicitly setting 'disable_existing_loggers' to True suggests that its 
default value is False and just omitting this line would leave existing 
loggers enabled. I think that at the very least we should change this 
attribute to False and note that it should be done like that due to 
Django's lazy setting initialization.


But in fact I'm not sure what to do here. May be even leave it as it is 
because the bug doesn't manifest itself in common scenarios… Thoughts?


--
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: HttpRequest.read() issues

[Ivan Sagalaev]

Graham Dumpleton:

Silly question. Where is the proof that using a limited stream is a
performance issue?


Last night I actually did test it :-). You're right the difference in
performance is less than a statistical deviation between different
uploads over network.

Tom Christie:

Even so, presumably we wouldn't want WSGIRequest to create a
LimitedStream object for _every_ single incoming HTTP request,
regardless of if it actually has a payload or not?

In that case deferring the LimitedStream creation, but always
ensuring that HttpRequest._stream is a LimitedStream rather than the
underlying stream would be a sensible thing to do.


And this one looks like another premature optimization :-). Creating a
single wrapper object is a negligible hit but the code bloat from making
it lazy is very real. So I'm -1 on laziness.


#15785 - HttpRequest.read(NUM_BYTES) can read beyond the end of
wsgi.input stream.

There is a patch (with tests) attached. [2]


Apart from the laziness issue your patch looks fine to me. Thanks!

--
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: HttpRequest.read() issues

[Ivan Sagalaev]

On 04/03/2011 07:03 AM, Tom Christie wrote:

It's not very obvious from the docs or source if HttpRequest.read() can
always be safely treated as a limited input stream, or if the developer
needs to respect HttpRequest.META['CONTENT_LENGTH'].

As far as I can tell the intention is that it can always be treated as a
limited stream, that seems to at least be the implication in
WSGIRequest.__init__, in which case it looks to me like there are two bugs.


Hello Tom,

I'll do my best to remember my intentions when this code was first 
written. But anyway it might need some fresh thinking. Thanks!


I've decided not to wrap streams in LimitedStream indefinitely because 
it would affect performance. I confess guilty for never actually 
measuring the hit but reading from connection seemed to me a hot enough 
place to operate as close to the socket as possible, especially because 
all the thing was made for performance-sensitive cases with potentially 
big request payloads.


In most practical situations request.read() was working just fine 
without the wrapper: mod_wsgi, mod_python, flup. The only exception at 
that time was the Django's runserver that would just hang when trying to 
read past content_length bytes. Actually there's a big comment on this 
matter right before LimitedStream wrapping in WSGIRequest.__init__. Also 
I thought that one could use LimitedStream explicitly in the user code 
if needed.



1. This code should not raise an Assertion Error...

 >>> from django.test.client import RequestFactory
 >>> req=RequestFactory().post('/', {'foo':'bar'})
 >>> req.read()
Traceback (most recent call last):
File "", line 1, in 
File
"/Users/tomchristie/workspace/django-rest-framework/env/lib/python2.6/site-packages/django/http/__init__.py",
line 296, in read
return self._stream.read(*args, **kwargs)
File
"/Users/tomchristie/workspace/django-rest-framework/env/lib/python2.6/site-packages/django/test/client.py",
line 51, in read
assert self.__len >= num_bytes, "Cannot read more than the available
bytes from the HTTP incoming data."
AssertionError: Cannot read more than the available bytes from the HTTP
incoming data.


Judging by svn logs this mock object (FakePayload) was written back at 
the days of uploads refactoring. Judging by its comment it is a safety 
measure to fail early and loud to protect client code from even 
attempting to read input stream past content_length.


So from all these here are my thoughts:

- I still believe that not using the limitator for everything is a good 
thing (doesn't break real code, doesn't degrade performance)


- It may be a good idea for a FakePayload to imitate real-world data 
providers and just return empty buffers when there's no data left.


Thoughts?


2. Isn't the use of LimitBytes in MultipartParser.parse() now redundant?


I didn't even know another such thing exists though I remember searching 
for it before writing LimitedStream. Now they just seem to be duplicates 
and it's a good idea to ditch LimitBytes (since LimitedStream implements 
a readline() too) and move it into some common place. http.utils seems a 
good fit for 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-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: Homogenization of User and UserProfile

[Ivan Sagalaev]

On 03/18/2011 07:22 AM, Carl Meyer wrote:

Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned
they bring almost nothing to the table except for the "there can be only
one" restriction


+1


Just use OneToOneField and the regular ORM access descriptors, and you
can have as many "user profiles" as you need.


True. Long ago I've coded a custom AutoOneToOneField[1] that implicitly 
creates a dependent profile object on first access. It turned out to be 
useful in many cases.


[1]: 
http://bazaar.launchpad.net/~isagalaev/+junk/cicero/view/head:/fields.py#L19


--
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: Homogenization of User and UserProfile

[Ivan Sagalaev]

On 03/15/2011 01:49 PM, Michael A. Ryan wrote:

In a typical client app, your User object is most
likely one robust object which you have to express in Django as both
User and UserProfile.


It's kind of hard to talk about "typical" Django app because there are 
so many different of them :-). However what's for sure is that 
significant share of Django projects consist of many apps. And those app 
may store their own profile information related to users. For example 
imagine some community site with a forum (an app), news comment system 
(another app) and anti-spam plugin (yet another app). A forum keeps 
track of users' achievements, comment system knows users' OpenID and 
anti-spam have a notion of users' karma. All those things are parts of a 
user profile.


If you think in these terms then the whole notion of a single default 
UserProfile becomes moot. Yes, it exists and does its job for simple 
situations but it's not a good ground for extensibility.



So when you go to pipe this information through
a tool like Django-Piston, you have to do a bit of slicing and dicing
in your handler code


Actually, you will have to do it anyway. Your API shouldn't just expose 
your internal model structure because it strongly couples interface to 
implementation. In any non-trivial systems APIs cannot be auto-generated.


--
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: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

[Ivan Sagalaev]

Hi Russell,

I seem to missed this email until lately… Here's my take on it if it 
still matters.


On 01/05/2011 08:29 AM, Russell Keith-Magee wrote:

  4) Modify cache_page to force a render of the response. This defeats
the purpose of introducing TemplateResponse, and would mean that
template response middleware would be executed, but ignored.


I'd go with a variant of this one. The purpose of TemplateResponse is to 
delay rendering but eventually it will be rendered anyway. And caching 
is an operation from which a user can expect the response to be baked.


However I think that baking is not the job for cache_page. Instead I 
think that TemplateResponse should bae itself whenever it's pickled.


--
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: Fetching results of a query set

[Ivan Sagalaev]

On 12/12/2010 06:45 AM, Alex Gaynor wrote:

Yes, if you're using iterator you'll have Django storing 100 items at a
time.  That being said I believe I read that some of the database
wrappers do their own caching (it's either mysqldb or psycopg2, I dont'
remember which).


They both do. They have their own explicit ways to use server-side 
cursors ([1],[2]) but not by default. There was a discussion here (or 
several) about the need to reevaluate the old decision in Django to 
stick to defaults but it was never actually done.


P.S. My personal opinion is that Django definitely needs an explicit way 
to control this both from settings and from queryset.


[1]: 
http://mysql-python.sourceforge.net/MySQLdb-1.2.2/public/MySQLdb.cursors.SSCursor-class.html

[2]: http://initd.org/psycopg/docs/usage.html#server-side-cursors

--
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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

On 12/01/2010 05:05 PM, Łukasz Rekucki wrote:

from django.conf import settings

def without_localization(view):
 @wraps(view):
 def decorated(*args, **kwargs):
 # NOTE: I'm assuming this will actually have any effect -
settings caching is a different issue
 old_value, settings.USE_L10N = settings.USE_L10N, False
 try:
 # If view uses HttpResponse, the template will be rendered
with USE_L10N = False
 # If it uses TemplateResponse, nothing will be rendered (yet!)
 return view(*args, **kwargs)
 finally:
 # USE_L10N will be back to it's original value
 # and that value will be used at the time of baking
 settings.USE_L10N = old_value
 return decorated


Ugh :-(. Thanks, I'll keep it in my notebook of examples where 
imperative style sucks…


But I see your point now. Indeed there are cases where TemplateResponse 
is not a transparent replacement for HttpResponse. I'll crawl back to my 
cave now and cry a little.


--
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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

On 12/01/2010 04:26 PM, Łukasz Rekucki wrote:

What about view decorators?

I don't want to invent use cases here, but if I right now have a view
decorator that on it's way out changes something that could alter how
a template is rendered (like current language, some settings or the
database contents), then changing to TemplateResponse will break this
view.


If you're talking about "right now" and "alter how a template is 
rendered" then this view either doesn't return an HttpResponse instance 
or returns its custom descendant. Hence such view won't be affected by 
introduction of a new shortcut or TemplateResponse.


What I'm talking about is that currently a middleware or a decorator 
that expects a normal HttpResponse instance can only access its headers 
or completely rendered content. The laziness of TemplateResponse can't 
break it.


May be I don't understand what you're trying to show here. Can you 
provide a small example?


--
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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

On 12/01/2010 02:52 PM, Łukasz Rekucki wrote:

Lots of people find render_to_response so verbose, that they are using
direct_to_template() view instead. Django 1.3 deprecates that one, so
it would be fair to offer those people a replacement. Forcing them at
the same time into the world of lazy baked responses isn't very fair,
imho.


It's not "forcing". TemplateResponse is a transparent replacement for 
HttpResponse. Normal response middleware shouldn't event notice that 
it's working with a TemplateResponse (modulo possible bugs in its 
implementation).


--
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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

On 12/01/2010 01:03 PM, Russell Keith-Magee wrote:

I'd argue it doesn't simplify anything. It saves you a grand total of
10 characters (plus a couple more on import), but at the cost of the
added complexity of having two ways of doing *exactly* the same thing.
There is also a loss of explicitness -- there's no doubting what
TemplateResponse will return.

On the other hand, there *is* value in adding a render() shortcut --
because there will be a subset of cases where a TemplateResponse isn't
needed, but a HttpResponse with a RequestContext is.


I'd argue :-) that these cases would be quite rare (in fact I can't even 
imagine one). And it'd be pity to use such delicious shortcut as 
'render()' for the rare case. Especially if we would recommend it as the 
default way of returning responses from users' views because then almost 
nobody would use TemplateResponse thus defeating its value altogether.


I understand why you don't like `render = TemplateResponse` but I think 
it's a minimal disturbance given the value that it provides.


Anyway I believe everyone here has expressed their points of view 
completely so now it's a judgement call for a committer.


--
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: .limit() on a QuerySet

[Ivan Sagalaev]

On 11/29/2010 11:31 PM, Christophe Pettus wrote:

Before I put any work into this, I want to know if (a) I'm missing something 
super-obvious in the QuerySet functionality, or (b) this idea has already been 
explored and rejected.


Hi Christophe,

Looks like you're indeed missing queryset slicing[1]. It is lazy.

[1]: 
http://docs.djangoproject.com/en/dev/topics/db/queries/#limiting-querysets


--
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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

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: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[Ivan Sagalaev]

On 11/28/2010 10:13 AM, Russell Keith-Magee wrote:

For your consideration, I present a patch to resolve #12815 and
#12816, adding a TemplateResponse and a render() shortcut.


Thank you!


  - The render() shortcut doesn't use TemplateResponse. Since render()
and TemplateReponse() have exactly the same prototype, I didn't see
the value in adding a shortcut that just redirected to a different
constructor. However, there is still value in making an easy-to-use
render_to_response, for those situations where a TemplateResponse
can't be used.


I have a slight (about -0) concern about this… It might turned out as 
the same mistake that was made with render_to_response() in the first 
place: it wasn't powerful enough (i.e. it didn't use RequestContext) to 
be used as a default shortcut. If people would like TemplateResponse 
they would be frustrated that render() doesn't use it. Using 
TemplateResponse directly is perfectly possible but then we have to 
explain to every newcomer why are there two slightly different ways of 
doing one thing. I think that cases where one wants to care about using 
pure HttpResponse instead of TemplateResponse would be rare and it's 
better not be the default behavior.


P.S. Noticed a typo in the patch:

@@ -164,6 +154,13 @@
 urlresolvers.set_urlconf(None)

 try:
+# Apply template response middleware and the bake the response
+# if the response can be baked
+if hasattr(response, 'bake') and callable(response.bake):

The first line of the comment should be "and the*n* bake the response".

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

[Ivan Sagalaev]

On 11/02/2010 05:27 PM, Mikhail Korobov wrote:

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


Full feature freeze is expected only by the time of beta so I don't 
think it's absolutely necessary to push it before alpha 1.


Anyway since I care very much for the patch I can pick it up if you 
couldn't find a time to maintain it. Just drop me a line off-list in 
this case.


--
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/CherryPy problem with POST data

[Ivan Sagalaev]

On 11/01/2010 08:44 AM, Russell Keith-Magee wrote:

The only changes I'm aware of making were related to getting
readline() to behave correctly. The patch as submitted didn't return
the right values for the readline(len) case. Which call to read() are
you saying is wrong?


Sorry, my memory has failed me here. Indeed I was thinking about your 
fixes in readline and they shouldn't have anything to do with the bug.


--
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/CherryPy problem with POST data

[Ivan Sagalaev]

On 11/01/2010 03:06 AM, Russell Keith-Magee wrote:

Sounds like a ticket is called for.


Mark, can you also CC: me ('isagalaev') on this ticket. I have an idea 
where it can be broken.


I remember that the initial patch was always passing a `size` parameter 
into .read() of the underlying stream. Russell can you remember why you 
changed it to pass or not pass the `size` according to how it was passed 
into the outer .read()?


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

[Ivan Sagalaev]

On 10/29/2010 09:58 AM, Russell Keith-Magee wrote:

I agree that it's important to treat people as grown ups. However,
this is something that is trivial to do by accident -- for example,
printing response.content would be an obvious debug step -- and it
will be a non-trivial thing to identify that this is the cause of your
problems.


Aha, I see the point now. On a second thought I think we can avoid this 
problem altogether by not passing actual response object into 
middleware. Instead we could pass just those bits that a middleware 
should care about: a template name and a context instance. The 
middleware then may (or even must) return new values for those that 
would be placed back into the response by the request handler.


Something still bothers me about it, but I can't invent any real 
objections myself.


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

[Ivan Sagalaev]

Russel:

Wouldn't it make sense to put a flag on the TemplateResponse
that prohibits accidental baking?


Mikhail:

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?


I don't think it's doable at all. People still can call any method in as 
well as they can ignore or alter any protection flag. I believe it's 
sufficient to abide to the Python way here, write a proper documentation 
and treat people as grown-ups trusting them not to do bad things in 
their process_template_response.


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

[Ivan Sagalaev]

On 10/28/2010 12:24 PM, Mikhail Korobov wrote:

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.


I'd say it's even worth to wait for 
http://code.djangoproject.com/ticket/14523 that moves response 
middleware application into the base code.


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

[Ivan Sagalaev]

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? :-)

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

[Ivan Sagalaev]

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

[Ivan Sagalaev]

Hi Russel,

On 10/22/2010 05:20 AM, Russell Keith-Magee wrote:

Jacob has already marked #9886 RFC, and on first inspection, the patch
looks good to me too; I want to have a closer look before I commit,
though. If you want to proceed assuming that #9886 will be committed
(i.e., make the fix for #14523 have #9866 as a prerequisite), I doubt
it would be wasted effort.


I didn't feel it would be wasted :-). I was going to start doing the new 
patch on top of my local bzr branch with #9886 applied (arent' DVCSes 
awesome?). What I meant is that I didn't want to actually attach a diff 
file to the ticket yet because it has chances of not being applicable 
against trunk.



Regarding the second problem you describe -- unless I'm mistaken,
Simon's TemplateResponse addresses this with his "baking" concept; a
response is baked the first time it is iterated or otherwise
evaluated.


The problem is that this iteration may (and does) happen after response 
is returned from the handler — and hence outside the `try .. except`. 
The point is to call baking explicitly right before the return.


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

[Ivan Sagalaev]

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/response.py#L85


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

[Ivan Sagalaev]

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

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

[Ivan Sagalaev]

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

[Ivan Sagalaev]

On 10/20/2010 11:51 PM, Mikhail Korobov wrote:

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


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.


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/response.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-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: Refactoring and file-like interface for HttpRequest

[Ivan Sagalaev]

On 10/02/2010 01:54 AM, Jacob Kaplan-Moss wrote:

On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev
<man...@softwaremaniacs.org>  wrote:

During a sprint before 1.2 I was proposing to commit my ticket [9886] that
deals with adding a .read() method to HttpRequest. Adrian suggested that it
was too late then and it's better to bring it up during 1.3 cycle. So here
it is.


Looks good to me - I moved it along. Thanks!


Thanks for a quick review!

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

Refactoring and file-like interface for HttpRequest

[Ivan Sagalaev]

Hello everyone!

During a sprint before 1.2 I was proposing to commit my ticket [9886] 
that deals with adding a .read() method to HttpRequest. Adrian suggested 
that it was too late then and it's better to bring it up during 1.3 
cycle. So here it is.


Basic summary of changes is in the first comment[1]. The patch is just 
updated to current trunk.


Thanks for your attention!

[9886]: http://code.djangoproject.com/ticket/9886
[1]: http://code.djangoproject.com/ticket/9886#comment:1

--
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: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote:

So, let me be clear on what you're proposing: you acknowledge that the
triage process is backlogged. Your proposal is to put extra workload
onto the core team - the one group that is already a bottleneck in the
process.


Pretty much. I just don't put it the way you do.

Triage process is backlogged not because of some strange reason. People 
need motivation to do daunting work and I can't imagine what could 
motivate enough volunteers to triage other people bugs regularly. And no 
amount documentation will fix this. A committer on the other hand is not 
just a volunteer. Being a committer of a high-profile open-source is a 
nice ego boost and committers receive more moral compensation than 
casual contributors. They are higher in an implicit project hierarchy 
and it matters to people.


As for bottleneck, I propose this only in light of Jacob's decision to 
increase the number of committers. This is certainly a prerequisite. 
It's not a question that committers are overloaded and this why this 
conversation has started.


To put it *really* short: I'm not trying to find extra work for 
committers, I'm bluntly saying that no one else would ever do it. So we 
have to find ways to do it. And having more committers and a simpler 
decision process does help here.



If you estimate that it takes an hour to close a ticket


This is BTW another, purely technical, problem. It shouldn't take an 
hour to close a ticket if it has proper tests. I was testing patches 
during various sprints and one big thing that I learned is that our 
whole test suit needs a deep refactoring to be simpler and faster. But 
this is another story...


--
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: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote:

Accepted tickets can be:

  * Purely accepted, indicating that someone has verified that the
problem exists, but not how to solve it

  * Accepted with a patch that is wrong in some way (e.g., fixing the
symptom, not the problem)

  * Accepted with a patch that is missing documentation or tests

  * Accepted with a valid patch, just awaiting review by someone else.

A ticket in the first three conditions patently isn't ready for
checkin. A ticket in the last condition *may* be ready for checkin; we
ask for independent verification before it gets moved to RFC.

So - IMHO "Accepted" plays a very important role in our triage system.


To me this shows exactly the opposite: a status that has so many 
meanings doesn't really mean anything useful :-). I'm not new in Django 
development yet as you see I managed to misunderstand its meaning in my 
previous mail.


Anyway, what I'm saying is that we have this huge gap between someone 
writing a good patch (with docs & tests) and the moment it gets into 
trunk. Current mechanism of volunteer triagers who are supposed to move 
such tickets from 'accepted' into 'ready for checkin' doesn't seem to work.


So let me mend my suggestion to better fit reality. Instead of removing 
'accepted' altogether (though I still think it's a good idea) I think 
each committer has to do this routinely. I know that every programmer 
would rather code instead of applying patches and running tests but the 
development process simply won't scale otherwise.


BTW, Bazaar guys use the approach with a "champion of the week". Every 
week a person from core committers volunteers to actively do triaging 
and committing new and old tickets in the tracker. May be such explicit 
approach would work for Django too. Especially since we're about to have 
more committers than we do now.


--
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: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

On 09/30/2010 01:40 AM, Chuck Harmston wrote:

In my world, the "accepted" status should only be used in one
circumstance: when a person is actively developing under or maintaining
a patch for the ticket. It's an indicator that someone has taken
ownership of a ticket, to prevent duplication of effort, etc. For
example, I accepted ticket #25 during the DjangoCon sprints to prevent
other developers at the sprints from attempting to develop against the
ticket.


I believe the field 'Assigned to' works just fine for this purpose, no?

--
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: ANN: Improving our decision-making and committer process

[Ivan Sagalaev]

Hello Jacob and everyone.

On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote:

Starting today, we're going to be making some minor but significant changes
to the way the Django core committer team "does business."


That's about time :-). Congratulations and thank you!

I have a comment and a suggestion:


This new process allows a proposal to be carried if:

* There are at least 3 "+1" votes from core committers.
* There are no "-1" votes from core committers.
* A BDFL hasn't issued a ruling on the issue.


This doesn't explain what's one is supposed to think in situation when a 
proposal is ignored by core devs, which may happen for all sorts of 
reasons. I suspect that "less than 3 +1 votes" means the same as any -1 
vote but I think that an explicit clarification would be nice.


---

My suggestion is about this unfortunate ticket status -- 'Accepted'. 
This now works as a sort of a dusty shelf: when anyone of the core team 
looks at the patch and decides that there's nothing wrong with it he 
puts it on that shelf where the ticket has all the chances to lie for 
months or even years. And if the author of the patch tries from time to 
time pitching it to get it into trunk he can easily fall into all sorts 
of "not-a-good-times": conferences, feature freezes, hot discussions on 
other topics etc.


My proposal is simple: 'Accepted' status shouldn't exist. If the patch 
is good it should be committed right away. If it's not there have to be 
an explanation why it needs improvement or why it's going to be 
wontfixed. Simple waiting doesn't really improve quality of the patch.


What do you think?

--
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: #717 (If-Modified-Since checked for exact match) should be fixed

[Ivan Sagalaev]

On 09/22/2010 12:13 PM, Luke Plant wrote:

On Tue, 2010-09-21 at 11:40 -0700, julianb wrote:

Uuh, so what's with this? Nothing happened with the ticket and no
further comments here either... :(


I accepted it on Trac, please see my comments there.  Also, you
mentioned about the 'condition decorator' that also needs updating - I'm
not sure what you meant, but if that isn't the same code path


This is it: 
http://code.djangoproject.com/browser/django/trunk/django/views/decorators/http.py#L47


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

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Ivan Sagalaev]

On 05/26/2010 03:02 PM, Gustavo Narea wrote:

Among many other things, one of the components alone provides solutions to some 
enterprise requirements for 
Django:

  * It’s now possible to run code at startup time, in a straight-forward yet 
extremely flexible fashion, which will also work on development servers if you 
want it to – not only when deployed on a production server.
  * You can now stop using a Python module to store your application settings, 
in order to use an intuitive and widely used
mechanism that scales up and scales down. It will just work and you won’t have 
to update any other file in your application.
  * By providing full WSGI support in development mode, we are able to  work around 
the differences in the process environment between django development server and 
django hosted using 
mod_wsgi
  * It’s finally possible to run WSGI middleware in development servers, the 
same way you may do it on production servers.

And this is just the tip of the iceberg.


Gustavo,

Could you please give a concise technical overview, in high-level terms, 
on what twod.wsgi actually does to Django code?


From the part that I quoted above I see that there are things that 
either don't have anything to do with WSGI (I'm fine with settings.py 
BTW) or don't explain anything (I didn't have problems with running 
Django under Paste along other WSGI apps).


P.S. I won't say for others but for me, as a developer, the phrase "just 
the tip of the iceberg" sounds scary, not attractive :-).


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

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

[Ivan Sagalaev]

George Karpenkov wrote:

Given your experience, the chances are that you're right, however, I
don't see any way how we can pass a generator which will not be called
until the form class is instantiated.


Why should a call matter? The body of the generator is not executed 
until first iteration attempt and can contain whatever lazy logic you need.


Can you provide an example where you need a function returning a list 
and generator wouldn't suffice.



b) it can be way more convenient to pass a function then a generator
expression (generator expression can be very hard to code if it has to
contain some complex logic)


I fail to see the difference here. A function that builds and returns a 
list is trivially converted into generator by replacing ".append(...)" 
with "yield ..." or replacing a list comprehension with a generator 
expression.


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

Re: Proposal - ChoiceField.choices need to accept callable, not only list or tuple

[Ivan Sagalaev]

George Karpenkov wrote:

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


I'm -1 on complicating it this way. The ability to pass a callable for 
choices is covered by passing a generator. Am I missing something?


--
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: Backwards-incompat with CsrfViewMiddleware

[Ivan Sagalaev]

James Bennett wrote:

Perhaps that's why, in both the 1.2 alpha release notes and the draft
for the final 1.2 notes, it's listed under a big heading titled
"backwards-incompatible changes".


As we say in Russia "Gee, I didn't notice the elephant" :-).

I still think it would be useful to add an explicit note about the 
possibility of breaking because of third-party apps.


--
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: Backwards-incompat with CsrfViewMiddleware

[Ivan Sagalaev]

Luke Plant wrote:
This case is slightly different because it is down to an interaction 
of a changed default setting with working code, but there will always 
be cases like that, and I think it is much better for developers to 
remember the general principle that they are responsible for whatever 
code they are running, whether they wrote it or not.


It's not the question of responsibility. We're changing a minor version 
which is supposed to be backwards compatible. If a site will break in 
this case people won't go looking for some responsible person they'll 
just blame Django for breaking a common expectation and creating a 
crunch job for them.


I should also point out the possibility of doing the csrf_exempt 
decoration in the URLconf, as with any decorator - I don't know how 
feasible that is in this case.


It's not. Because third-party apps typically provide their own urlconf 
along with their own views.


Again, it's not the matter of how to fix it, there are plenty of ways to 
do it. But if our changes are backwards incompatible we should clearly 
say so in upgrade/release notes.


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

Backwards-incompat with CsrfViewMiddleware

[Ivan Sagalaev]

Hello everyone!

A couple of days ago we've noticed a (potentially big) backwards 
incompatibility that can bite users upgrading from 1.1 to 1.2.


CSRF doc encourages users to enable CsrfViewMiddleware that will check 
all POST requests for csrf_token and then suggests to alter all HTML 
forms to include one or wrap in @csrf_exempt those views that accept 
POSTs generated elsewhere. This however is no help for views in 
third-party apps that users don't control. So their site would be broken 
until those apps are updated.


This has actually happened lately to users of my OpenID server library 
that was missing @csrf_exempt.


I won't try to estimate the amount of breakage that this will incur so 
I'm just shedding a light on the issue. May be some Big Fat Warning™ 
should be added to docs or even they should be rewritten to suggest 
using individual decorators instead of a middleware.


--
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: [Python-Dev] PEP 391 Acceptance - Thanks!

[Ivan Sagalaev]

Vinay Sajip wrote:

Guido,

That's great - thanks very much! I'll get on with integrating the PEP
391 implementation into trunk right away, and it should be in good
time for 2.7/3.2.


Thank you for your efforts!

--
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: Feedback requested: Multi-db database routing

[Ivan Sagalaev]

Russell Keith-Magee wrote:

class MasterSlaveRouter(object):
def db_for_read(self, model, db=None):
# Point all read operations to a random slave
return random.choice(['slave1','slave2'])

def db_for_write(self, model, db=None):
# Point all write operations to the master
return 'master'

def allow_relation(self, obj1, obj2):
# Allow any relation between two objects in the db pool
db_list = ('master','slave1','slave2')
if obj1 in db_list and obj2 in db_list:
return True
return None

Then, in your settings file, add the following:

DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.MasterSlaveRouter']

And you're set.


It's more of a side note.

I understand that this is only an example but examples like this one 
might give an impression that Django now solves master-slave replication 
out of the box. It's not.


The hard thing about replication is that switching between master and 
slaves doesn't depend on models and doesn't depend on SQL operators. It 
depends on some vague notion of "operation context": if we are in some 
logical multi-step process of changing state then all writes *and* reads 
should happen on a master or we won't have a consistent transaction.


That said, this routing looks to me like a convenient and may be even 
necessary plumbing. It just doesn't solve the whole problem.
-- 
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.

Master/slave replication in multi-db era

[Ivan Sagalaev]

Russell Keith-Magee wrote:

There are some cases where this shouldn't happen - for example, in a
master/slave setup. I'm tinkering with some code at the moment to
control this sort of database allocation.


Russel, can you share your ideas on the matter? I'm about to port 
(soon-ish) my replication backend to new multi-db reality and if you 
already had some thoughts I'd very appreciate to hear 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: Logging format decision

[Ivan Sagalaev]

Russell Keith-Magee wrote:

You've also defined a production server that uses just two loggers -
exception and info - for the entire server. Again, this isn't
especially realistic - in practice, you have a large number of fine
grained loggers for different parts of the system.


In fact, most of our production services use just two loggers: one for 
exceptions and one for everything else. So that one with maintenance was 
the most interesting :-). But see below...



I think I understand what you're advocating - I just think you've
missed some very important use cases.


And I do understand what you and Vinay are saying. I really don't miss 
those use-cases. I intentionally try to avoid them in practice to not 
complicate things.


But since you both feel that they are indeed important so be it, let's 
make it this 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: Logging format decision

[Ivan Sagalaev]

Russell Keith-Magee wrote:

That said - I really do want to see logging in Django's trunk. If we
can sort out the details in the background and get a good
implementation ready, it could easily be the first feature committed
for v1.3.


Agreed!


I like Vinay's suggestion for exactly the reason you dislike it. The
definition of a handler is independent of the loggers that use that
handler. Simon's example in (4) hides a lot of details behind ellipses
- if you expand those ellipses, you discover that there is a lot of
repeated typing of '/tmp/django-sql.log' etc if you want all your logs
to appear in the same file. Under Vinay's proposal, you define a
single file log handler, and instruct each of the loggers to use that
handler.


Actually, I don't see this problem of repetition that you're describing 
so I thought that we could use some examples closer to real world to 
sort this out. May be I just don't see something obvious to you or have 
misunderstood Vinay's schema. I will refer to two formats we're 
discussing as "explicit handlers" (Vinay's) and "implicit handlers" 
(what Simon has implemented). Better suggestions for naming are welcome :-).


1. The first use-case is the development environment where all you want 
is everything logged in one file with DEBUG level.


"Implicit handlers":

LOGGING = {
'': {
'handler': 'django.logging.FileLogger',
'filename': '/home/user/myproject/all.log',
'level': 'debug',
},
}

"Explicit handlers":

LOGGING = {
'formatters': {
'all': '%(asctime)s %(name)-15s %(levelname)-8s %(message)s',
},
'handlers': {
'all': {
'class': 'django.logging.FileLogger',
'filename': '/home/user/myproject/all.log',
'formatter': 'all',
'level': 'debug',
},
},
'loggers': {
'': {
'handlers': ['all'],
},
},
}

2. A production environment. This actually what we have for one of our 
services:


- a file for uncaught server errors that are logged by a function 
listening to `got_request_exception` signal which uses 'exception' label 
to log
- a file for maintenance messages that come from cron scripts that all 
use 'maintenance.*' labels to log

- a file for everything else

"Implicit handlers":

_log_path = '/var/log/service/'

LOGGING = {
'exception': {
'handler': 'django.logging.FileLogger',
'filename': _log_path + 'exception.log',
'format': '%(asctime)s %(levelname)-8s %(message)s',
'level': 'warning',
'propagate': False,
},
'maintenance': {
'handler': 'django.logging.FileLogger',
'filename': _log_path + 'maintenance.log',
'format': '%(asctime)s %(name)-15s %(levelname)-8s 
%(message)s',

'level': 'info',
'propagate': False,
},
'': {
'handler': 'django.logging.FileLogger',
'filename': _log_path + 'info.log',
'format': '%(asctime)s %(name)-15s %(levelname)-8s 
%(message)s',

'level': 'info',
},
}

(Note: "propagate" is not implemented right now in Simon's code but is 
quite easy to add).


"Explicit handlers":

_log_path = '/var/log/service/'

LOGGING = {
'formatters': {
'exception': '%(asctime)s %(levelname)-8s %(message)s',
'default': '%(asctime)s %(name)-15s %(levelname)-8s 
%(message)s',

},
'handlers': {
'exception': {
'class': 'django.logging.FileLogger',
'filename': _log_path + 'exception.log',
'formatter': 'exception',
'level': 'warning',
},
'maintenance': {
'class': 'django.logging.FileLogger',
'filename': _log_path + 'maintenance.log',
'formatter': 'default',
'level': 'info',
},
'info': {
'class': 'django.logging.FileLogger',
'filename': _log_path + 'info.log',
'formatter': 'default',
'level': 'info',
}
},
'loggers': {
'exception': {'handlers': ['exception'], 'propagate': False},
'maintenance': {'handlers': ['maintenance'], 'propagate': 
False},

'': {'handlers': ['info']},
},
}

In both examples "implicit handlers" give shorter code and, to me, are 
more readable.


The main point that I'm trying to argue is that having handlers and 
loggers *separate* is not needed in real world scenarios. If you want 
your logging in several files you will have to define several handlers 
and several loggers anyway. "Implicit handlers" format accept this fact 
and couples both handler and logger definitions in one place.


The only thing that 

Re: Model validation incompatibility with existing Django idioms

[Ivan Sagalaev]

Joseph Kocherhans wrote:

# Run validation that was missed by the form.
p.validate_fields(fields=['user', 'primary_contact'])
p.validate_unique(fields=['user', 'primary_contact'])
p.validate()


Can this be shortcut to

p.full_validate(fields=['user', 'primary_contact'])

?

If not, why not? :-)
-- 
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.

Logging format decision

[Ivan Sagalaev]

Hello everyone!

There was a discussion here some time ago about logging in Django that 
led to the ticket 12012 [1] where Simon has done most (all?) of the 
implementation.


There is still a disagreement on the format of the configuration dict 
for it. Simon has implemented it from my ad-hoc proposal [2]. Vinay 
Sajip has an alternative suggestion [3]. I think a core-dev ruling is 
due here.


To state my own opinion, I sill like my format better because it defines 
each logging channel in one place without needing to separately define 
formatters and handlers. I understand that it makes it less powerful but 
I'd rather have a very simple format here -- we still can configure 
logging imperatively in advanced cases.


I'll be happy to do some docs and tests for the ticket once it's decided 
(as far as I can see Simon's branch lack them).


[1]: http://code.djangoproject.com/ticket/12012
[2]: 
http://groups.google.com/group/django-developers/msg/7452fac3ae3b8175 
(look for item 4)

[3]: http://mail.python.org/pipermail/python-dev/2009-October/092782.html
-- 
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: Model validation incompatibility with existing Django idioms

[Ivan Sagalaev]

Tobias McNulty wrote:

I don't see why model validation should be bound up with forms at all.


I'm not the one who designed it, so it's just me view. I think this is 
just useful: if you have a code validating, say, a CharField at the 
model level why not reuse it at the form level?


What's important is that *entire validity* of a form should not be bound 
to that of a model. This was a bug which Joseph Kocherhans is now fixing.


 The current release notes for model validation state that it won't be 
done unless explicitly requested by the developer, and it seems that 
validating the model inside a form (whether fully or partially) breaks 
that contract.


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

Re: Model validation incompatibility with existing Django idioms

[Ivan Sagalaev]

Tobias McNulty wrote:

I regret and apologize that I'm arriving to this thread rather late.


To support the tradition, I'm apoligizing for this too :-). Though it's 
funny how everyone thinks they're "late" on a couple-of-days-old thread :-).


Anyway...

I too would opt for an implementation that makes model validation 
optional, i.e., a call that developers must explicitly make, if they 
choose, before saving a model.


I'm +1 on some way of validating a form without *fully* validating a 
model. But for a bit different reason that I didn't see in this thread yet.


The thing is that validating a ModelForm may not be strictly related to 
subsequent saving of an instance. A use-case:


I have a PreviewForm that generates a preview for a comment that user is 
writing in a form. It uses model fields to validate currently typed text 
and selected markup filter and then creates a model instance to do 
actual formatting:


class PreviewForm(ModelForm):
class Meta:
model = Comment
fields = ['text', 'markup_filter']

def preview(self):
comment = Comment(
text = self.cleaned_data['text'],
filter = self.cleaned_data['markup_filter'],
)
return comment.html()

It is then used like this:

def preview_view(request):
form = PreviewForm(request.POST)
if form.is_valid():   # <- this now breaks
return HttpResponse(PreviewForm.preview())

The thing is that the code has no intention to save an instance into a 
DB. It just needs it at application level. This is why I think that 
decisions on "full" vs. "partial" validation should not be bound to 
`save()`.


(FYI currently the first patch (Joseph's) in #12521 does fix this 
problem while the second patch (Honza's) doesn't. From a quick look this 
is beacuse the second patch only excludes fields from validation that 
listed in `exclude`).
-- 
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: idea for using RequestContext by default

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> Certainly - and Simon made exactly this proposal during the review of
> the CSRF work. Simon even provided a sample implementation:
> 
> http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1

Thanks! I keep missing nice things on django-dev@ due to many *-dev 
lists traffic :-(

--

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: idea for using RequestContext by default

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> I'm in complete agreement with Simon on this point. I fail to see the
> benefit of decorators in this context.

I can see one valid point that "render_to" guys have. Which is, 
incidentally, has nothing to do with the decorator syntax. An 
HttpResponse with an opaque string as its content is hard to alter after 
it is returned from a view (one of the precedents was the old 
CsrfMiddleware was parsing HTML to inject a token). And most of the real 
use-cases for this are about adding something to the view's context 
before it blends in a template. Right now the only way to do it is with 
context processors but they are global, not per-view, which is not 
convenient.

I think it can be solved another way, by something like a special 
HttpResponse subclass -- TemplateResponse. It can keep a template and 
its context separate until the very last moment when its contents is 
asked and only then do render a template.

This will allow extension of the views:

 # some library:

 def library_view(request):
 # ...
 return TemplateReponse('template.html', context = { ... })

 # user code:

 def my_view(request):
 response = library_view(request)
 response.context.update({ ... })
 return response

Russel, can you see something like this in Django trunk?

--

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 #5025 - truncate filter, why hasn't it been accepted?

[Ivan Sagalaev]

Alex Gaynor wrote:
> Adding the ellepsis is as simple as:
> 
> {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %}

Come on Alex, in what universe it qualifies as "simple"?!

--

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: What do people think about the get_absolute_url proposal?

[Ivan Sagalaev]

Mike Malone wrote:
> In my opinion, using the Site module and settings files is damn
> annoying.

My point is that we better fix these annoyances than leave this way of 
doing things altogether.

> I never use the Site module

This is by itself is not the reason why it might be annoying. Django 
actually recommends its usage in documentation and if you don't follow 
it then, why, some level of annoyance is expected.

>, and in my experience having to
> change the "FRONTEND_URL" of your app every time you push to a
> different environment is tedious and a frequent source of subtle
> problems.

Indeed. This is why there's Site model. It's better than a setting 
because it's per-database, not per-installation.

I agree that having to maintain a record in Site is also not ideal. But 
it can be made less error-prone:

- syncdb could interactively ask for scheme/host/port instead of using 
"example.com" (that would fix all *my* problems with SIte)
- correct set of sites can live in initial_data fixture

> Moreover, the request information in your current request
> _should_ always be correct.

Agreed. But it's not the whole point I'm arguing.

> That said, it sounds like there are a number of special cases where it
> would be useful to override these settings. So maybe the best corse of
> action is to try to use the configured Site information and fall back
> on "RequestSite", which uses information from the currently active
> request.

This might work, I think. Anyway I can't bash this idea with anything 
from the top of my head :-). I'll think of it a bit more.

--

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: What do people think about the get_absolute_url proposal?

[Ivan Sagalaev]

Michael Richardson wrote:
> With these cases (the former more so than the latter) you are creating
> URLs for an entirely separate project, not your own, essentially.

Not "entirely separate". These are projects sharing much of the 
codebase, just having different SITE_ID in settings.

Anyway there's still my first use-case of constructing URLs from 
standalone scripts.

> We pass around request objects all over the place in order to get this
> functionality.  request.build_absolute_uri is great, but it does
> require that request object and passing it around - which sucks.

request.build_absolute_uri works for you because you don't have those 
use-cases. This is why we see this way differently: you think that 
having a request universally available makes things more convenient 
while in my view it doesn't fix URL construction at all[*] and just adds 
a bit to the mess in thread-locals. And I kind of disagree that my 
use-cases very exotic.

[*] URL construction is really broken right now because I am forced to 
hard-code 'http://' or 'https://' in my script that sends mail by cron.

--

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: What do people think about the get_absolute_url proposal?

[Ivan Sagalaev]

Mike Malone wrote:
> Well, not really. It's making a way to generate a URL based on the
> request object global. I agree that it's not ideal, but it's not the
> same as just making the request object global.

My main gripe is not globalness of a request object itself (I agree with 
"not ideal" here) but the very idea of constructing a URL from request.

> You wouldn't have any trouble in a standalone script unless you tried
> to call the get_absolute_url() function.

But I kinda want that. Here's two more usecases where using current 
request for creating URLs is broken:

- If I have an API part of the service and human-readable part of the 
service on different hosts and I want to construct a reference to API 
when serving user pages.
- If have several machines behind a load-balancing proxy that's not 
under my control and that's not telling me its hostname I don't want to 
construct URLs with internal hostnames of individual machines in cluster.

In other words there are legitimate real-world cases when "current" 
requests has nothing to do the URL I want to cnstruct.

> I will reiterate that, in practice, this is a huge pain in the ass.

Can you provide an example? My experience doesn't match this. My only 
minor complaint is that I sometimes forget to update default 
"example.com" generated for Site model on new installation (which should 
be fixed differently, IMO).

--

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: What do people think about the get_absolute_url proposal?

[Ivan Sagalaev]

Mike Malone wrote:
> On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee
>  wrote:
>>  4. I share Mike's concern about using settings.SITE_ID to determine
>> the current host, but I'm not sure I have any suggestions on how we
>> could practically use request, short of encouraging the use of a
>> template tag like {% obj_url %} that can use data from the request
>> context if it is available.
> 
> It's not exactly pretty, but: http://paste.pocoo.org/show/155827/

All these are variations of the same thing: making request object 
global. Do we really want it?

For one thing it breaks what Django has always got right: being able to 
work in a script outside of a web request loop. So relying on 
contrib.Site may be inconvenient but it's way better than a global 
request. What I take from code like this:

 protocol = getattr(settings, "PROTOCOL", "http")
 domain = Site.objects.get_current().domain
 port = getattr(settings, "PORT", "")

... is not that we should get all these from a request but that we 
should add "protocol" and "port" fields to the Site model.

--

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: Conventions around plugable backends

[Ivan Sagalaev]

On topic, I'm +0 on class-based approach.

There's actually one passage that reminded me of something that I 
consider a small wart in a couple of places in Django:

Russell Keith-Magee wrote:
> Module-based configuration:
> ---
> 
>  * The aesthetic of user-configuration options is cleaner because
> configuration items are shorter and don't require duplication of
> terms. e.g., django.core.cache.backends.locmem.LocMemCacheBackend
> duplicates the 'locmem' bit for no real end-user gain unless you're
> planning to have a non-locmem backend in the locmem package.

Nothing forces people to duplicate module name in class names. This same 
class could be named "django.core.cache.backends.locmem.Backend". It 
also encourages a good style of importing the entire module and 
referring to its content with a prefix:

 from django.core.cache.backends import locmem
 backend = locmem.Backend()

--

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: Reversing URL for a view with namespaces

[Ivan Sagalaev]

Ivan Sagalaev wrote:
> Ahha! This is the catch I was missing. So in order for an app to place 
> itself generally in the "namespace-aware" category it should define a 
> function that will return a triple of (patterns, app_namespace, 
> instance_namespace) and document it as the only way of including itself 
> in a project's urlconf.
> 
> This makes sense now. Thanks!

And now with my newly found understanding I think I've found a small bug 
(and may be a bigger one). Looks like this:

 include(myapp.urls.urls, app_name='custom_app_name')

is supposed to override whatever myapp provides as an app_name with 
user-specified value 'custom_app_name', right?

But now it doesn't. Here's an excerpt from `include`:

 def include(arg, namespace=None, app_name=None):
 if isinstance(arg, tuple):
 # callable returning a namespace hint
 if namespace:
 raise ImproperlyConfigured('Cannot override ...')
 urlconf_module, app_name, namespace = arg

A final `app_name` here is extracted from `arg` that an application 
provides, not from `app_name` parameter. If this is really a bug I'll 
happily make a patch (it's small).

A bigger (possible, provided I understand things right) bug is that 
include explicitly forbids redefinition of `namespace` for an app that 
*does* provide its own namespace. But as we just concluded a 
namespace-ignorant app just can't be included under a namespace. So 
specifying a namespace in include is a) not possible for "old" apps and 
forbidden for "new" ones. How come?

--~--~-~--~~~---~--~~
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: Reversing URL for a view with namespaces

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> Apologies for taking so long to get back to you on this.

No problem :-) Have busy schedule myself :-)

> For this last case - building a new app that you want to be namespace
> aware - I think the Django admin already implements the model that
> needs to be followed here. I can't think of any obvious way to allow
> for an application to be 'namespaceless', as well as potentially one
> of many in a namespace. Admin solves this by *always* requiring a
> namespace - even if that's just the default application namespace.
> Django's URL namespace lookup makes the simple case easy, (i.e.,
> admin:named_url works, regardless of how you have deployed admin),
> while allowing for multiple namespaces.

Ahha! This is the catch I was missing. So in order for an app to place 
itself generally in the "namespace-aware" category it should define a 
function that will return a triple of (patterns, app_namespace, 
instance_namespace) and document it as the only way of including itself 
in a project's urlconf.

This makes sense now. Thanks!

> All this leaves is catching (and preventing) the case of deploying
> applications that aren't namespace aware inside a namespace. For
> this... patches welcome :-)

I'll try to look into it when someone reminds of a concept known to 
other people as "free time"...

--~--~-~--~~~---~--~~
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: Reversing URL for a view with namespaces

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> On the 'missing something' front, reverse() now takes a 'current_app'
> argument that gives context to the app lookup, which resolves the
> ambiguity from the point of view of the reverse() function.

I saw this one. It doesn't work in this case exactly beacuse of this:

> This solves the problem as long as applications have been built to
> provide a namespace.

Which means an app knows its exact namespace.

> However, this doesn't fully address the 'bug' you
> describe - an application that hasn't been built to accept namespaces
> will have problems if it is deployed in a namespace.

There's important detail here.

One thing is a namespace-ignorant application that just uses reversing 
the old way. I don't think we can fix it in any way except saying 
somehow "don't install this app under a namespace" (as you suggested).

Another thing is an application that is being written now and that wants 
to be namespace-aware. The problem is that while an application knows 
that it can be included under a namespace it doesn't care under which 
one exactly.

As far as I can tell it can be solved by keeping views in 
resolver.reverse_dict as it was before namespaces were introduced as 
well as in namespace_dict and app_dict. This way they could be found 
both by specifying a name with or without namespace. However it doesn't 
solve the problem when you have two instances of the same application. 
For this we should have a way for an application to know which instance 
of it is "current". Which means tying reversing to a request (right?). 
At this point I didn't come up with anything more useful...

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

Reversing URL for a view with namespaces

[Ivan Sagalaev]

Hello!

I've just stumbled upon a difficult to understand problem. I have an app 
  that has an urlconf which is included in a project under a namespace:

 (r'^blog/', include('app.urls', namespace='blog')),

This namespace allows things like {% url blog:article ... %} which is 
very nice. But reversing doesn't work when an app itself tries to 
reverse its own urls having a callable at hand:

 reverse(views.article, args=[...])

It doesn't work because namespaced URLs are basically excluded from 
resolver's reverse_dict and are put in their own resolvers under 
namespace_dict. And reverse doesn't traverse those when it gets a callable.

On one hand I can see logic here: trying to reverse a namespaced URL 
without specifying a namespace can lead to ambiguous results. But in 
practice it means that one can break any third-party app that reverses 
its URLs (using models.permalink, redirect, or reverse) just by 
including its urlconf under a namespace. Because an app doesn't know its 
namespace and then has no way of constructing a correct URL.

Am I missing something or is it an evil bug?

--~--~-~--~~~---~--~~
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: #9886: HttpRequest refactoring

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> Any complete feature is potentially a candidate for
> v1.2 - as long as you can convince a core developer to look into the
> ticket.

This is what I'm trying to do, yes :-). The ticket is assigned to 
Malcolm (and in fact it was created after we talked with him if such a 
thing is needed) but he's incredibly busy lately so I decided to discuss 
it here to get someone else interested.

> It's also worth noting that one of the GSoC projects was "HTTP/WSGI
> improvements". If you want to get #9886 into trunk, I suspect you
> would be well advised to see how your patch integrates with the
> changes on the soc2009 branch for that project.

I had that in mind from the beginning of that GSoC but didn't look at 
the code yet. Since the ticket is older than the GSoC branch there were 
chances that it would be committed earlier. But of course I'll  keep an 
eye on the process.

 From a fast superficial look at the code we don't seem to conflict 
anyway :-)

--~--~-~--~~~---~--~~
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: #9886: HttpRequest refactoring

[Ivan Sagalaev]

Jacob Kaplan-Moss wrote:
> On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev
> <man...@softwaremaniacs.org> wrote:
>> Ticket [9886] is one of the things that I've been holding for 1.2 time
>> frame to ask for some discussion since Jacob marked it DDN.
> 
> At first glance, you need docs and tests before you get a second glance :)

Hello again!

I've finally got back to the ticket and added docs and tests. For docs 
I've extended the reference in request-response.txt which, being a 
reference, is short. I could write a longer topic document with more 
example if needed. I just don't know if it's worth to make a whole new 
topic for a rather advanced and not commonly-used feature.

Also I've proposed this ticket for 1.2 on the wiki[1]. Is this enough to 
get it in the decision process or should it be added into a spreadsheet 
as well?

[1]: http://code.djangoproject.com/wiki/Version1.2Features#HTTP

--~--~-~--~~~---~--~~
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: Best place for code that processes stuff from settings.py once (for logging implementation)

[Ivan Sagalaev]

Benjamin Slavin wrote:
> * Logging may need to come even earlier.  If you truly want to log
> everything, you'll want to run that code first.

Is it really the case that we want to log everything? I believe that 
logging after initialization is enough. And for my example of a logging 
handler that uses ORM it's the only way it can work. Initialization by 
definition shouldn't do anything interesting for an application 
programmer to look for, it should either succeed or fail with an 
exception saying that it "can't run your program, sorry".

As it stands now loading and processing of all the settings is the point 
  that marks success of initialization. So I'm with Simon in putting 
logging somewhere where all the other settings get processed.

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

Re: Proposal for 1.2: built-in logging with django.core.log

[Ivan Sagalaev]

Vinay Sajip wrote:
> We should provide a configure_logging(dict) utility function which 
> takes a dict in an agreed format (such as Ivan's suggestion). Then in
> settings.py users can invoke configure_logging(LOGGING) after
> defining the configuration right there, in settings.py itself, or
> obtaining the dict from any other source. This avoids any "magic" (by
> LOGGING being automagically processed) and allows advanced users to
> configure "by hand" if they so wish.

I see one problem with explicitly calling a function from settings.py. 
This will execute instantiation of handlers and all the user staff very 
early when settings aren't fully configured yet. This prevents a user to 
have a handler that will use Django models for example. In general 
settings should be as dumb as possible for easy bootstrapping. This is 
why all those middleware/context processors/backends etc are strings and 
not actual callables.

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

Re: Proposal for 1.2: built-in logging with django.core.log

[Ivan Sagalaev]

Sorry for taking a bit long to respond. Looks like we aren't disagree 
much anyway but I had to get some thoughts off my chest :-).

Vinay Sajip wrote:
> It's similar to Django's support for, say, simplejson. I think it's
> reasonable for Django to alias WatchedFileHandler so that it's
> available either bound to logging's own implementation (in
> sufficiently recent versions of Python) or else a copy in Django's own
> code. Then people can use it if they want to, even in older Python
> versions.

Agreed.

> I have no big problem with a configuration scheme such as you suggest
> - if it's felt that a lot of Django users are not Python-savvy enough
> and need some hand-holding

Uhm... No this is not about hand-holding or something like that. I 
propose a format that is shorter and more convenient than the 
ConfigParser's. This is the point.

> My reservation with Django's own take on it is simply
> that it goes against TOOWTDI and the Zen of Python, a little at least.

Yes, this is the bad part about it. However the Zen of Python is not a 
dogma and its application is subjective. I think my proposal still 
stands and the decision is left for core devs. As for me I'll most 
probably play with the implementation of parsing of this format for our 
own projects anyway. I'll file it as a ticket if I would still like it 
by that time :-).

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

Re: Proposal for 1.2: built-in logging with django.core.log

[Ivan Sagalaev]

Ivan Sagalaev wrote:
> Standard Python logging configuration has 
> a noticable gap between very simplistic basicConfig which configures 
> only a root channel and a verbose imperative definition of handler 
> objects, formatter objects and logger objects.

Forgot one thing. As it stands now Django has this "historic" behavior 
when it imports and executes settings module twice. This results in 
breakage when you setup loggers and handlers by hand. We now circumvent 
this by having a helper function that memoizes configured loggers and 
call it from settings.py. Having a declarative config we can hide this 
inside of Django and not scare users.

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

Re: Proposal for 1.2: built-in logging with django.core.log

[Ivan Sagalaev]

Vinay Sajip wrote:
> Actually you don't need much in settings.py, and Django doesn't need
> to grow any code of its own to "wrap" logging. You can either
> configure logging programmatically (for which I use basicConfig, in
> simple setups) or using a configuration file (ConfigParser-based,
> fully documented in Python docs) for more complex setups.

Thanks! Didn't know that. However see my further comment.

>> Now we've settled on a WatchedFileHandler ported from Python 2.6 logging
>> module. It watches for file descriptor change and doesn't require
>> SIG_HUP to pick up a new file. May be we should port it to Django and
>> use it as a default handler for logging to file system.
> 
> Why "port it to Django"? Do you mean, copy it into Django? I'm not
> sure it should be the default - not everybody uses logrotate. I'd
> leave this sort of decision for code in settings.py.

Using WatchedFileHandler is a safe default because it works as 
FileHandler, just doesn't break with logrotate. I don't know of any 
disadvantages of WatchedFileHandler before the old FileHandler. So I 
don't think there's much value in giving people this choice in settings 
because non-default behavior will be rare (and still possible anyway).

One of the reasons why I propose Django's own settings structure for 
logging is because we can choose better defaults for logging and have 
more compact syntax for them. Standard Python logging configuration has 
a noticable gap between very simplistic basicConfig which configures 
only a root channel and a verbose imperative definition of handler 
objects, formatter objects and logger objects. I've found that my usage 
of logging inevitably falls in between: I often need a few logging 
channels but I almost never, say, reuse handler objects between them.

Here's a variant of a simple config that I had in mind lately:

LOGGING = {
 'errors': {
 'handler': 'django.logging.FileLogger', # WatchedFileLogger copy
 'filename': '...',
 'level': 'debug',
 },
 'maintenance': {
 'handler': 'logging.handlers.HTTPHandler',
 'host': '...',
 'url': '',
 'format': ''
 },
}

Top-level keys are logger names. Values are dicts describing handlers. 
These dicts have several keys that Django knows about:

- 'handler': a handler class. It's imported like any other stringified 
classes in settings

- 'level': a level keyword that is translated into logging.* constants. 
This is done to not make users import logging by hand.

- 'format': a format string for the logging.Formatter object. We can 
have a more sensible default for this than the one in Python logging. Or 
not :-)

These keys are pop'd out of the dict and the rest is used as **kwargs to 
the handler class instantiation.

Django's default setup may look like this:

LOGGING = {
 '': {'handler': 'logging.StreamHandler'}
}

This has an advantage of always configuring a root logger to avoid an 
infamous warning from Python logging when the logger doesn't have any 
handlers defined. Users wanting to configure all the logging themselves 
may null-out this using `LOGGING = {}`.

--~--~-~--~~~---~--~~
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: #9886: HttpRequest refactoring

[Ivan Sagalaev]

Jacob Kaplan-Moss wrote:
> On Thu, Sep 17, 2009 at 10:09 AM, Ivan Sagalaev
> <man...@softwaremaniacs.org> wrote:
>> Ticket [9886] is one of the things that I've been holding for 1.2 time
>> frame to ask for some discussion since Jacob marked it DDN.
> 
> At first glance, you need docs and tests before you get a second glance :)

I believe my follow up about this that I've posted a bit erlier will 
eventually get to Google Groups :-).

I'm going to make them of course. Now I just wanted a general answer 
along the lines "okay this looks sane" or "no we don't need 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-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: #9886: HttpRequest refactoring

[Ivan Sagalaev]

Ivan Sagalaev wrote:
> This comment[1] in the ticket is a summary of what had changed. Thanks 
> for looking!

Forgot to add... There's no docs & tests changes in the patch yet. I'll 
add them after the decision if this looks good at all.

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

#9886: HttpRequest refactoring

[Ivan Sagalaev]

Hello everyone!

Ticket [9886] is one of the things that I've been holding for 1.2 time 
frame to ask for some discussion since Jacob marked it DDN.

This has started as a feature allowing to .read() directly from a 
request object. However this has lead to a rather nice refactoring 
removing a lot of code duplication in wsgi and modpython handlers.

This comment[1] in the ticket is a summary of what had changed. Thanks 
for looking!

[9886]: http://code.djangoproject.com/ticket/9886
[1]: http://code.djangoproject.com/ticket/9886#comment:1

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

Re: Proposal for 1.2: built-in logging with django.core.log

[Ivan Sagalaev]

Hi Simon,

Simon Willison wrote:
> 1. We'll be able to de-emphasise the current default "e-mail all
> errors to someone" behaviour, which doesn't scale at all well.

In a recent thread[1] on a similar topic Russel has also emphasized that 
we should improve documentation about doing logging.

> 3. Logging in Django core rather than a 3rd party app will encourage
> reusable applications to log things in a predictable way, standard
> way.

Talking about predictable and standard way I want to be sure that we 
don't break existing logging.

I.e. we at Yandex now have many reusable Django apps that don't setup 
loggers themselves but just log things into named loggers and expect 
them to be setup by a project that uses them.

What I gather from your proposal is that you want the same model ("an 
app logs, a project setups") plus a nice declarative syntax in 
settings.py instead of boring creation of handlers, formatters and 
loggers. Right?

> - We could replace (or complement) django.connection.queries with a
> log of executed SQL. This would make the answer to the common question
> "how do I see what SQL is being executed" much more obvious.

In the thread that I was referring to[1] we kind of agreed on using a 
signal there. Then hooking a logger onto the signal is simple.

> 5. People might leave logging on, then find their server disk has
> filled up with log files and caused their site to crash.

We had this problem with standard logging. Then we switched to a 
RotatingFileHandler which wasn't very good however because its behavior 
is simplistic and is not controllable by admins with an interface that 
they know, namely logrotate. Setting up logrotate also wasn't without 
problems. When it rotates a file it should let an app know about it and 
it uses SIG_HUP for that. However this instantly terminates Django's 
flup-based FastCGI server which we use.

Now we've settled on a WatchedFileHandler ported from Python 2.6 logging 
module. It watches for file descriptor change and doesn't require 
SIG_HUP to pick up a new file. May be we should port it to Django and 
use it as a default handler for logging to file system.

> 6. Logging levels are confusing - what exactly is the difference
> between warn, info, error, debug, critical and fatal? We would need to
> document this and make decisions on which ones get used for what
> within the framework.

May be we can just leave it for users to decide. It depends so much on 
how much an app actually wants from logging.

The only standard thing I can think of is to have DEBUG = True imply 
level = logging.DEBUG (which includes everything more sever). DEBUG = 
False will imply logging.INFO then. What do you think?

> # If you want custom log handlers - not sure how these would interact
> with
> # channels and log levels yet
> LOG_HANDLERS = (
> 'django.core.log.handlers.LogToDatabase',
> 'django.core.log.handlers.LogToEmail',
> )

This is a hard problem really. Most handlers require different set of 
arguments. File names, email credentials, system idents for SysLog etc. 
Also there should be different formatters. For example there's no point 
to waste space in a syslog message on a timestamp since syslog tracks it 
itself...

[1]: 
http://groups.google.com/group/django-developers/browse_frm/thread/9d0992e800cf7d68#

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

James Bennett wrote:
> Except I can't help thinking this is an awfully arbitrary distinction
> to draw. In effect you're saying that nearly every question about an
> object should be answerable by interrogating it directly, *except* for
> "what's a URL I can use for you?"

May be I can explain this distinction with an example.

We once had two different web sites about "events". They both had a 
"core" set of models but each one had their own set of views & urls. So 
for a core Event model a question "what's your URL" just didn't make 
sense. It had two different URLs depending on the project it was 
imported in.

That said, I do see a value in having a default URL (and a default 
__unicode__ for that matter) simply because it's useful in many (or even 
majority?) of real-world cases.

So Yuri, Patrick, this method is optional so there's not technical need 
to deprecate it. This discussion really is about how it should be done, 
not if.

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

Zachary Voase wrote:
> If you take a look, you’ll notice that URLObject, being a subclass of  
> unicode, can be used *directly* within the template and it'll render  
> out to the URL without any magic.

Beware! Using the word "magic" too loosely may infuriate certain core 
devs and they will start hunting you all over the globe, or worse, 
strike you out of a Christmas present list for this year!

Honestly, having an object that looks like unicode but at the same time 
able to be /-ed or |-ed with another unicode in my dictionary *is* 
called "magic".

I still fail to see why this clever micro-DSL is needed when all this 
can be done with normal Python and be more clear.

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

Jacob Kaplan-Moss wrote:
>>>  schema, domain, path, query, fragment = urlsplit(obj.url())
> 
> That's not in any way intitutive for a new user in the way that
> `obj.url().schema` is.

After thinking of it a bit more I agree about new users. My main concern 
though was about not using an established pattern.

>> Oh... And for template authors we could just make 5 filters returning
>> those parts:
>>
>> {{ obj.url|domain }}
> 
> So we need *five* new built-in filters instead of `{{ obj.url.domain
> }}`? Why? What if I want to access the username or password? Do we
> "just" add two more filters?

Looks like I shouldn't have posted that follow-up :-). It was only an 
afterthought. Actually I think we don't need even those 5 filters 
because there are no clear use cases for all of them. If we need schema- 
and host-relative URLs then we need exactly two filters:

 {{ obj.url|schema-relative }} (or better "protocol-relative")
 {{ obj.url|host-relative }}

I think it's better than, say:

 //{{ obj.url.domain }}{{ obj.url.path }}?{{ obj.url.query }}

The filter is also useful for {% url %}-generated URLs using {% filter 
%}. Which I believe is not doable with url-as-an-object thing.

Thoughts?

--~--~-~--~~~---~--~~
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: media -> admin_media Prefix Change

[Ivan Sagalaev]

drozzy wrote:
> Sorry about the attitude, sometimes I think a bit too much of myself.
> When do you think will get implemented?

I'm not the one who decides :-). I've just raised another voice claiming 
that that decision may be worth reconsidering.

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

Ivan Sagalaev wrote:
> In the rare cases when I do need to split a URL into parts I just use 
> urlsplit:
> 
>  schema, domain, path, query, fragment = urlsplit(obj.url())

Oh... And for template authors we could just make 5 filters returning 
those parts:

 {{ obj.url|domain }}

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

Jacob Kaplan-Moss wrote:
> * The fact that the returned URL is a string often means I end up
> doing something like `obj.get_absolute_url().split('/')`. Objects are
> better.

I kind of disagree with the last sentence here. An object in place of a 
well-known native type (here, str) adds another abstraction to grok for 
a newbie. It's like when you read WinAPI docs and see a function 
accepting structs of structs of structs and changing some memory buffer 
but you only have a string and want to get an int. I mean it boils down 
to it anyway, just not obvious from the start...

In the rare cases when I do need to split a URL into parts I just use 
urlsplit:

 schema, domain, path, query, fragment = urlsplit(obj.url())

I believe it's a well-known pattern for an experienced pythoneer.

So I'm against of introducing a new Django-specific way of doing 
urlsplit that has chances to confuse both newbies and gurus for 
different reasons.

--~--~-~--~~~---~--~~
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: media -> admin_media Prefix Change

[Ivan Sagalaev]

drozzy wrote:
> Yes, I Do, How about that he never replied to the Collin Grady's
> commend about HOW it would break the code.
> Seems like the ticket was never discussed but monopolized by a little
> hush-hush discussion...

Though I don't support this attitude I tend to agree on principle with 
drozzy and various people in the bug comments. Having a nice default is 
good and backwards compatible patch is available. Why not do it then?

--~--~-~--~~~---~--~~
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: Replacing get_absolute_url, I am against it

[Ivan Sagalaev]

drozzy wrote:
> If it is going to be done I propose adding another function, and thus
> have two possible functions on the model:
> get_relative_url
> get_absolute_url

get_relative_url is rather misleading. The proper meaning of "relative" 
is a url relative to current url: "./some/hierarchy", "some/", ".". Put 
simply it's a path that doesn't start with a slash. The problem is that 
on the model layer no notion of a current url exists so this makes 
get_relative_url even more weird.

--~--~-~--~~~---~--~~
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: Logging instead of connection.queries

[Ivan Sagalaev]

Hello!

I'd like to revive the discussion about handling debug SQL log since I 
don't feel we've come to any conclusion. To summarize:

- Ticket [5415] deals with implementing signals upon SQL queries. Nobody 
had any objections to it and it helps in solving my original problem of 
logging.

- Malcolm has a patch that limits connection.queries to some finite size 
which will solve perceived "memory leak" problem for newbies. After 
additional thinking I decided to refrain my proposal of disabling 
populating connection.queries by default since it wouldn't pose 
immediate problems in this case.

If I haven't missed anything are we agree then that those two changes 
should be in 1.2 on principal?

If yes, I have another little thing to discuss about ticket 5415 
implementation. It introduces another cursor wrapper (apart from 
CursorDebugWrapper) that actually sends signals. I think we could just 
put this code into the Cursor itself and get rid of the wrapper. It 
makes sense to have signals for both debug and production modes and the 
common knowledge is that signals are cheap enough. Right?

[5415]: http://code.djangoproject.com/ticket/5415

--~--~-~--~~~---~--~~
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: Logging instead of connection.queries

[Ivan Sagalaev]

Malcolm Tredinnick wrote:
> Unfortunately, this ticket doesn't solve Ivan's problem of the moment,
> as far as I can see.

Yeah, it sends signals in addition to maintaining connection.queries. My 
point  (or one of them) is to replace current hard-coded implementation 
with something lower-level and less intrusive and then reimplement 
connection.queries on top of it. And the disable it by default.

I'm happy with signals by the way. This is consistent with the way 
Django reports unhandled exception in core.handlers.base.

--~--~-~--~~~---~--~~
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: Logging instead of connection.queries

[Ivan Sagalaev]

Malcolm Tredinnick wrote:
> Adrian, in particular, has been historically against adding logger
> module hooks in Django. So you have to work around that.

Interesting... Adrian, can you elaborate?

> I have a patch I've been holding over for 1.2 that reduces the current
> debug wrapper's log method to a ring buffer to avoid the accidental
> massive memory usage case.

Actually this is not the main issue... I saw the discussion about 
limiting the buffer. My main concern is that logging is way more 
flexible there. Having ability to watch queries before execution or log 
failed queries in non-debug mode -- things like that is what I really 
pursue here.

--~--~-~--~~~---~--~~
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: Logging instead of connection.queries

[Ivan Sagalaev]

Russell Keith-Magee wrote:
> For the record, there is one notable use for the legacy behavior -
> debugging at the console. i.e., issue a query at the Python prompt,
> then print connection.queries[-1] to see what was executed.

Yes, and we can keep it. As I said a simple custom log handler can do this:

 class QueriesHandler(logging.Handler):
 def emit(self, record):
 time, sql = record.split(' ', 1)
 connection.queries.add({
 'time': time,
 'sql': sql,
 })

Then we can invent a structure in settings to easily define handlers:

 LOGGING_HANDLERS = [
 ('django.sql', 'django.logging.QueriesHandler'),
 ]

Or something more configurable with levels, params, etc. But these are 
details... From this point my proposal is more like "let's make internal 
implementation of SQL logging configurable".

> Most databases have extremely configurable logging and analysis tools
> - if Django started moving into this territory for logging queries, we
> would be duplicating functionality pretty much from day 1.

Apart from what Yuri said, there's another thing you cannot do with DB 
logs: you cannot have it in one file with other logs from your Python code.

(Mostly agreed with your other notes.)

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

Logging instead of connection.queries

[Ivan Sagalaev]

Hello!

A couple of days ago a sudden thought has struck me while thinking on 
the matter of logging in Python libraries. I consider a good practice 
for a library to log what it's doing into a named logger without setting 
up logging by itself. It's then a responsibility of an application that 
would use the library so set up logging as it see fit.

In this vein I propose to teach CursorDebugWrapper to log SQL queries 
into a named logger instead of storing them into connection.queries. 
Before writing a patch I want to discuss it.

This would look like this:

 import logging
 log = logging.getLogger('django.sql')

 class CursorDebugWrapper(object):
 def execute(self, sql, params=()):
 # 
 log.debug('%.3f %s' % ((stop - start), sql))

Or actually this will allow to eliminate CursorDebugWrapper altogether, 
do the logging in the standard cursor and control it by setting a 
logging level on a handler in this fashion:

 import logging
 logging.basicConfig(
 filename = '...',
 level = settings.DEBUG and logging.DEBUG or logging.WARNING,
 )

Some advantages of this approach are:

- Logs can be directed to several handlers. Tools like 
django-debug-toolbar and firebug can have their handlers to catch SQL on 
the fly.
- Logging happen in real-time. Currently most debugging tools analyze 
connection.queries after a request has finished.
- Several logs can be combined into one handler. This helps to see what 
code triggers SQL execution.
- We can log queries also before execution. This helps catching 
killer-queries that take forever to execute.
- Such logging will eliminate a typical newbie question "Why Django 
leaks memory" when people don't know that SQL is stored in memory in 
DEBUG mode.

For backward compatibility there may be a custom logging handler that 
would maintain connection.queries as is. But the user will have to 
explicitly switch it on.

--~--~-~--~~~---~--~~
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: Long-term direction for shortcuts

[Ivan Sagalaev]

Malcolm Tredinnick wrote:
> As a general process, I'm inclined to think it's the wrong direction --
> making namespaces larger and larger. That way lies PHP or web2py.

Having read your replies in this thread I refrain from speaking about 
general directions :-). This one was about particular issue of two 
http-related modules.

> You
> can already write
> 
> from django.view.decorators import http as decs
> from django import http
> 
> and it's two short lines. I think, though, that this shows the real
> problem: we have a few overlapping names like this that are unfortunate
> and historically entrenched.

Yeah this was the main point. I understand that views.decorators.http 
dates back to first release of Django and that django.http was initially 
just a container for HttpRequest and HttpResponse. But now I think it's 
more convenient to have just one module for all HTTP-related mechanics. 
We already have plenty utils in django.http, why not merge two 
decorators into them?

> Working out
> how to jam things together won't result in everybody being pleased in
> any case.

Pleasing everybody is never the goal. It is unreachable whether we do 
anything at all or not :-)

--~--~-~--~~~---~--~~
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: Long-term direction for shortcuts

[Ivan Sagalaev]

Brent Hagany wrote:
> The issue of making shortcuts better (and decreasing the number of
> imports in views.py files) was brought up at DjangoCon

Another angle on the issue of reducing imports is that we can do it not 
with shortcuts only but by packing some smaller modules into larger 
ones. For example just yesterday I've stumbled upon this in my views:

 from django.views.decorators.http import require_POST, condition
 from django.http import HttpResponse, HttpResponseRedirect, \
 HttpResponseForbidden, HttpResponseBadRequest, Http404

And thought that it would be way better to merge both modules into a 
django.http and then I could just

 from django import http

and use everything in it with just a 5-letter prefix.

What people think 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-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: HTTP Errors

[Ivan Sagalaev]

Forest Bond wrote:
> But your model code shouldn't have HTTP-related bits buried in it.  That's a
> layering violation.  That code should raise a more generic exception that your
> view code converts to an HTTP response.

Yes, this is may be more correct way. But having one exception without a 
conversion chain is just simpler. I'm fine with calling it AccessDenied 
instead of Http403 :-). Though thinking of this now I'm not that sure 
that it should be in Django by default, it smells more like a custom 
solution...

--~--~-~--~~~---~--~~
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: HTTP Errors

[Ivan Sagalaev]

Marc Fargas wrote:
> You could write an Exception middleware that takes care of processing
> your "special" exception. Bu anyway, note that you are willing is to
> give "response" so the right thing to do would be returning a response
> object

The latter is not very convenient. Often the code that makes a decision 
about forbidding something is buried deep into model layer and can't 
easily return an HttpResponse. So I believe that making a special 
exception and converting it into an HttpResponseForbidden in a 
middleware is a good way to do this in current Django code. But I can 
really see the value of making it a part of Django even if just for the 
sake of consistency with Http404. BTW other HTTP errors in my practice 
don't work by this pattern so I don't propose making an exception for 
everything >= 400.

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