Re: Revisiting multiline tags

[h3]

I would also like to know more about the rational behind ditching the
idea of
multilinetags.

{% trans with
 varname=myobject.proprety1
 someothervar=myobject.some.other_property
 yetanothervar=myotherobject.with_a_painfully_long_method_name
 "Even with line-wrap, it's a pain to read on a single line."
%}

Forcing a Python developer to write something like this on a single
line
is borderline cruel.

Besides, it's backward compatible (I think so) and it doesn't break
syntax highlighting (in Vim at least).

+1


On Feb 18, 1:04 am, Glenn Washburn 
wrote:
> Hello django devers,
>
> I'd like to reopen discussion on the multiline tag issue 
> (see:https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.
>
> I've done rudimentary testing on a 6 character change in 1.3.1 to
> template.base.tags_re (add the re.S flag to the regex), which appears
> to solve the issue.  So I don't see all the work which was being
> referred to in mtredinnick's point two.  Perhaps the template engine
> has been rewritten since then.  The only test that fails after making
> this change (in 1.3.1) is the one that explicitly tests that tgs should
> not be multiline.
>
> Since this change appears to be so low impact and such a simple
> change.  Are there any reasons why this change shouldn't be included in
> django?  Maybe I'm missing something.
>
> Its interesting to note thathttps://code.djangoproject.com/ticket/3888, which 
> is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.
>
> -Glenn

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

Revisiting multiline tags

[Glenn Washburn]

Hello django devers,

I'd like to reopen discussion on the multiline tag issue (see:
https://code.djangoproject.com/ticket/8652) which was closed 3 three
years ago as "won't fix".  The last comment notes that this won't
happen as the decision has been made many times.  But there is no link
to any discussion on this topic, so I can only assume mtredinnick's
point two is the supposed reason for not fixing this.

I've done rudimentary testing on a 6 character change in 1.3.1 to
template.base.tags_re (add the re.S flag to the regex), which appears
to solve the issue.  So I don't see all the work which was being
referred to in mtredinnick's point two.  Perhaps the template engine
has been rewritten since then.  The only test that fails after making
this change (in 1.3.1) is the one that explicitly tests that tgs should
not be multiline.

Since this change appears to be so low impact and such a simple
change.  Are there any reasons why this change shouldn't be included in
django?  Maybe I'm missing something.

Its interesting to note that
https://code.djangoproject.com/ticket/3888, which is referenced in the
issue, is also closed as "won't fix", but appears to be allowed in
1.3.1.  So there is a precedent for "won't fix" issues being included.

-Glenn

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

user_logged_in signal

[meitham]

Is there any reason why getting the redirect_to path in
django.contrib.auth.views.login()
"""
Displays the login form and handles the login action.
"""
redirect_to = request.REQUEST.get(redirect_field_name, '')

happens before we actually call the auth_login(request,
form.get_user())
The auth.login is what fires the user_logged_in signal anyway and its
handler have access to modify every bit of the request. However the
redirect_to URL was already read by then and the end of the view we
have
return HttpResponseRedirect(redirect_to)

Does it make sense to reread the redirect_to after we do the security
checks instead of before
So this:
# Use default setting if redirect_to is empty
if not redirect_to:
redirect_to = settings.LOGIN_REDIRECT_URL

# Heavier security check -- don't allow redirection to a
different
# host.
elif netloc and netloc != request.get_host():
redirect_to = settings.LOGIN_REDIRECT_URL

# Okay, security checks complete. Log the user in.
auth_login(request, form.get_user())

Becomes this
# Okay, security checks complete. Log the user in.
auth_login(request, form.get_user())

# Use default setting if redirect_to is empty
if not redirect_to:
redirect_to = settings.LOGIN_REDIRECT_URL

# Heavier security check -- don't allow redirection to a
different
# host.
elif netloc and netloc != request.get_host():
redirect_to = settings.LOGIN_REDIRECT_URL


This way if we decide to change the redirect_to for that request it
will be picked by login view.
Is there any security implications for doing this?

Meitham

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

Re: Django 1.4: call for release blockers

[Anssi Kääriäinen]

On Feb 18, 11:28 am, Aymeric Augustin
 wrote:
> Hello,
>
> 1.4 beta arrived a bit late, but we'd like to catch up and release RC1 before 
> the end of the month.
>
> Until then, we're going to focus on:
>
> 1 - Release 
> blockers:https://code.djangoproject.com/query?status=!closed=Release%...

There are two release blockers related to the new prefetch_related
feature which needs some attention.

The first one is out of my comfort zone: it is about what DB to use
for prefetching when .using() has been called for the main queryset.
Currently the database which happens to be in use for the related
queryset will be used. That is, the main queryset's .using() has no
direct effect for the prefetch. Maybe use the database of the main
queryset if the related queryset doesn't _explicitly_ use any
database? I really don't know this area. I checked the original ticket
for prefetch_related and the conclusion there was that lets leave this
for later, we don't know this area. Any multidb-people willing to
help? The ticket is #17696.

The second one is about .iterator() and .prefetch_related()
interoperability. They are mutually exclusive (you need to fetch all
the objects before you can do prefetch. However, .iterator() says do
not fetch all the objects in one go...). There are basically three
ways forward: raise an error, favor .iterator() (current behavior) or
favor .prefetch_related().

I think each one has some merit, and this is mostly bike-shedding.
However, if you have good reasons for one of the options it would be
good to hear them now. I would prefer either error or doing the
prefetch even when iterator is used. As I don't recall ever actually
using .iterator() in production I have no strong opinions. The ticket
is #17668.

 - Anssi

-- 
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: Validation error in Slovak: question about URL language code sniffing

[Anssi Kääriäinen]

On Feb 17, 8:55 pm, Ryan Kaskel  wrote:
> Hi all,
>
> I ran my project's tests today using the new beta and was surprised
> when one innocuous-looking test failed because the expected English
> validation error string didn't match the returned Slovak equivalent.
>
> It turns out that this view is accessible with URL whose path begins
> with "/sl/". Ticket #11585 [0] and its associated commit [1] (which
> are fairly old) changed
> django.utils.translation.get_language_from_request by adding the
> get_language_from_path hook. Since my site uses the LocaleMiddleware,
> this change activates the Slovak language for the request. Validation
> errors and other available translated strings end up being in a
> language I don't really want to use.

To me this seems like a release blocker. Django can't suddenly start
changing language because of some URL prefix, it is backwards
incompatible as seen by the above.

I created a ticket for this and marked it as a release blocker. I
attached a patch which disables language activation based on url-
prefix if i18n_patterns isn't used in root urls. This way the language
activation takes place only if you use i18n_patterns, that is, you are
actually using the feature.

The ticket is #17720. Please help by reviewing it! If full review
feels daunting, just do some of the following:
  - check that this solves your issue
  - check that the docs do not need changes

Add a comment describing your findings. Especially the first item
would help a lot!

 - Anssi

-- 
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: MySQL connection pooling - preferred method??

[Anssi Kääriäinen]

On Feb 18, 1:01 am, Florian Apolloner  wrote:
> Yes, ABORT + DISCARD should do it for postgres (or ABORT; RESET ALL; SET
> SESSION AUTHORIZATION DEFAULT if pg < 8.2)

Inspired by this thread, I did some work for 3rd party database
connection pooling. What I have is at https://github.com/akaariai/django_pooled.
Quick summary: seems to work, except for Django's tests.

Now, there is a problem regarding connection state initialization.
Django doesn't separate between creating a connection and initializing
its state. All is done in ._cursor(). If the above were to work
reliably, the implementation of ._cursor() should be:
def _cursor(self):
 if not self.connection:
  self.connection = self.new_connection()
  self.initialize_connection()
 return CursorWrapper(self.connection.cursor())

Now a pooling connection wrapper could just override new_connection()
in a subclass and everything should work. The connection returned from
the pool would still get properly initialized. This change would make
sense from code-clarity and consistency between backends point of
views, too. So, I think doing this refactoring would be a good idea.

Note that the connection-state initialization problem doesn't really
matter in the normal usage. However, in Django's test suite, where the
connection initialization will do different things depending on
overridden settings (settings.USE_TZ for example) things will break.

The above mentioned change is what I have meant when I have said that
Django should encourage extensibility: create nicely extensible
implementations. They need not be public API.

BTW You should not run ABORT + DISCARD ALL as connection reset string
in PostgreSQL from Python. Two reasons: abort == rollback, and this
means psycopg2 will lose track of transaction state. In addition
DISCARD ALL will reset the connection state, and due to the problem of
not separating new connections and initialization of connection state,
this will mean connection state will be incorrect for second
connection onwards. Just do connection.rollback(). ABORT + DISCARD ALL
is still the right thing to do in external poolers (pgpool2, pgbouncer
etc).

I think what I have should work for MySQL, too. I have tested it for
PostgreSQL and SQLite3, where things seem to work. Except for the
above mentioned state-init problem.

So, anybody interested in connection pooling should in my opinion work
for making Django's backends more extensible, and then creating a 3rd
party connection pooler. What I have might be a good starting point,
or at least it might give some pointers of what to do.

Note that connection pooling in Python for speed reasons does not make
sense. You will get much better results from external pools, which can
view the application as a whole. In-Django pool is limited to one
process at a time view, which isn't good at all. However, there are
some other nice things you could do: reporting of most time consuming/
used queries. Rewrite normal queries to prepared statements/procedure
calls. Track where you have left transactions open. Share connections
in auto-commit mode (this would actually make a _lot_ of sense from
performance standpoint in read-only views). I did some of those in
another pooler experiment: https://github.com/akaariai/django-psycopg-pooled

 - Anssi

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

Django 1.4: call for release blockers

[Aymeric Augustin]

Hello,

1.4 beta arrived a bit late, but we'd like to catch up and release RC1 before 
the end of the month.

Until then, we're going to focus on:

1 - Release blockers:
https://code.djangoproject.com/query?status=!closed=Release%20blocker

2 - RFC tickets -- unless they're new features:
https://code.djangoproject.com/query?status=!closed=Uncategorized=Ready+for+checkin=!closed=Bug=Ready+for+checkin=component

If you notice a bug in the beta that is:
- a major bug in a new feature, or
- a regression from 1.3, or
- a crashing bug, or
- a data loss bug,
then you should report it in Trac as soon as possible and set "severity" to 
"release blocker".

Thanks for helping us make Django 1.4 a high quality release!

Best regards,

-- 
Aymeric.

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