Re: Session/cookie based messages (#4604)

[SmileyChris]

On Oct 16, 2:04 pm, Tobias McNulty  wrote:
> Just to make sure I understand this correctly, let me try to summarize
> what this would mean:
>
>  * the proposed app controls {{ messages }} and is responsible for
> retrieving anything set in the Message model

Thanks to Luke's work with lazy messages, we can keep now let
contrib.auth processor continue to set {{ messages }} - we'll just
override it (and state in docs that it must be placed after
contrib.auth processor)

>
>  * old apps that call user.message_set.create will still get their
> messages to the screen, assuming the project uses {{ messages }} in
> the template
>
>  * old apps that call get_and_delete_messages or iterate through the
> Message.objects.all() manually will NOT see any messages that were
> stored in the session or a cookie, but they will continue to see
> messages created the old way
>
>  * judging from your code, the new app will NOT store any messages in
> the old Message model, it will only read them
>
>  * the standard template code:
> [snip]
> will continue to work untouched after the update.  For those that
> choose to leverage it, a {{message.level}} (or otherwise named
> attribute) will also be available.

Yes x4
>
>  * since we are tying ourselves to the {{ messages }} variable, this
> probably means that the app should be called 'messages'.  There has
> been some hesitation about this.  Are we in the clear now that we have
> a potential upgrade path from the old API?  Or is there still concern
> about naming?

I'm happy with keeping the name "messages" now that it has been
indicated that the User messages should be deprecated.
It makes the upgrade path easier.
--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Tobias McNulty]

On Thu, Oct 15, 2009 at 7:03 PM, SmileyChris  wrote:
> If we are to slowly deprecate this functionality, I think that we
> should do effectively the same thing.
> Leave user messages as-is and use something like this as the default
> message storage:

Just to make sure I understand this correctly, let me try to summarize
what this would mean:

 * the proposed app controls {{ messages }} and is responsible for
retrieving anything set in the Message model

 * old apps that call user.message_set.create will still get their
messages to the screen, assuming the project uses {{ messages }} in
the template

 * old apps that call get_and_delete_messages or iterate through the
Message.objects.all() manually will NOT see any messages that were
stored in the session or a cookie, but they will continue to see
messages created the old way

 * judging from your code, the new app will NOT store any messages in
the old Message model, it will only read them

 * the standard template code:

{% if messages %}

{% for message in messages %}
{{ message }}
{% endfor %}

{% endif %}

will continue to work untouched after the update.  For those that
choose to leverage it, a {{message.level}} (or otherwise named
attribute) will also be available.

 * since we are tying ourselves to the {{ messages }} variable, this
probably means that the app should be called 'messages'.  There has
been some hesitation about this.  Are we in the clear now that we have
a potential upgrade path from the old API?  Or is there still concern
about naming?


-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

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

Re: Session/cookie based messages (#4604)

[SmileyChris]

On Oct 16, 12:03 pm, SmileyChris  wrote:
>
> class LegacyFallbackStorage(FallbackStorage):
>     storage_classes = (UserMessageStorage, CookieStorage,
> SessionStorage)

Here's a working implementation even: 
http://code.google.com/p/django-notify/source/detail?r=35

No need to panic, django-notify users - I haven't made it the default
storage.
--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[SmileyChris]

On Oct 16, 5:56 am, Tobias McNulty  wrote:
> On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss  
> wrote:
> > I'm trying to avoid having two incompatible messaging systems in
> > Django. I agree that linking messages to sessions makes more sense
> > than linking them to users [1], but we can't just remove the user
> > messages API outright. I'd like a good transition strategy, so it
> > seems the best way would be to keep the user messages API, but switch
> > it to use session messages under the hood.
>
> I know a solution like this was attempted and then abandoned earlier
> in the ticket history.

To summarize how it worked:
* user messages were left as they are (database call and all)
* session messages were added
* a new context processor handled lazily combining both message
sources into a {{ messages }} context variable

>
> Chris, do you have any wisdom to share about this?  I expect it may be
> complicated because I can't think of a clean way to get the current
> request (and hence the session messages variable) inside the User
> model.

I can't see how it can work either (without some evil threadlocal-
ing).

If we are to slowly deprecate this functionality, I think that we
should do effectively the same thing.
Leave user messages as-is and use something like this as the default
message storage:

class LegacyFallbackStorage(FallbackStorage):
storage_classes = (UserMessageStorage, CookieStorage,
SessionStorage)

If someone knows they don't need user messages at all, they can set
NOTIFICATIONS_STORAGE = FallbackStorage
--~--~-~--~~~---~--~~
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: shortcut proposal

[dc]

Note that there is another way:

direct_to_template(request, 'template_name.html', context)

But i think that fixing render_to_response is good idea.
--~--~-~--~~~---~--~~
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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Wes Winham]

The common use case on my projects is definitely to trim whitespace.
The autostrip decorator I found on djangosnippets (http://
www.djangosnippets.org/snippets/956/) is pretty awesome, but I'd
prefer not to import that into every project and it would be nice to
not call:

> MyForm = autostrip(MyForm)

on practically every form I have with a CharField

What's the common use case for allowing a user to add a space at the
end of a datetime field or email field, or pretty much any text field?
It seems like that those situations are in the minority and the strip
argument would make things simpler for the simple case while remaining
backwards compatible.

-Wes

On Oct 10, 5:47 pm, Taylor Marshall 
wrote:
> I'd love to see this change get put in.  I think the most common case
> for forms is to trim whitespace, not the other way around.  I'd rather
> have the extra work come in for the rare case (when you wanted to
> preserve leading/trailing spaces).
>
> -Taylor
>
> On Oct 10, 11:37 am, Barry Pederson  wrote:
>
>
>
> > On May 13, 2:56 am, Russell Keith-Magee 
> > wrote:
> >  >On Wed, May 13, 2009 at 7:48 AM, thebitguru  wrote:
>
> >  >> Hi,
>
> >  >> What do we need to make a decision for ticket 6362 (http://
> >  >> code.djangoproject.com/ticket/6362)?
>
> >  > We need to wait until we're not trying to get v1.1 out the door.
>
> >  > We are well past the feature deadline for v1.1; the focus of the
> >  > community is on fixing bugs and finalizing the v1.1 release. Once that
> >  > happens, we will be in a position to concentrate on design decisions
> >  > again.
>
> > Now that we're talking about 1.2, I hope this can be looked at before
> > the door closes again.  Either this or the simpler patch from
>
> >    http://code.djangoproject.com/ticket/4960
>
> > Having extraneous spaces in user input is quite annoying and can cause a
> > fair amount of trouble.  Yes, you could write custom validation for
> > every single one of your forms, but a global fix is potentially pretty
> > trivial.
>
> > Some other tickets complaining about the same problem with specific
> > field types are:
>
> >    http://code.djangoproject.com/ticket/5714
> >    http://code.djangoproject.com/ticket/11907
>
> >         Barry
--~--~-~--~~~---~--~~
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: Dumber email validation

[Ulrich Petri]

> Russell raises my biggest concern with this proposal.  There are
> a lot of smart folks in the Django-Developers end of things that
> can cobble together a pretty legit regexp that covers the
> majority of cases with no horrific DOS cases (e.g. last security
> issue).
>
...
> My initial candidate is ticket #12005, though it merely
> re.VERBOSE's the original and tweaks the domain portion to meet
> an internal need.  Some changes on the stuff before the "@" might
> make it more "relaxed" (if not RFC-compliant-ish) while keeping
> out some of the badness.
>

Of course it would also be possible to use a non-regex approach. There
are libraries by Dominic Sayers [1] and Cal Henderson [2] with a ton
of tests. Unfortunately they are written in PHP but shouldn't be to
hard to translate to Python. As a bonus the authors claim these
libraries to validate fully RFC compliant.

Ulrich

[1] http://www.dominicsayers.com/isemail/
[2] http://code.iamcal.com/php/rfc822/
--~--~-~--~~~---~--~~
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: shortcut proposal

[flo...@gmail.com]

+1

On Oct 15, 10:45 am, Luke Plant  wrote:
> Hi all,
>
> As a consequence of the proposed CSRF changes, we brought up wanting
> to add a shortcut like render_to_response that uses RequestContext, as
> a refinement, but didn't decide on anything.  Ideally, we would have
> something as short as this:
>
>  return render(request, "template_name.html", {'foo':'bar'})
>
> Currently you can do this:
>
>  return render_to_response("template_name.html", {'foo':'bar'},
>              context_instance=RequestContext(request))
>
> This is a bit cumbersome, especially with the need to import
> RequestContext as well as render_to_response.  My proposal: add
> 'request' as a keyword argument to this same function:
>
>  return render_to_response("template_name.html", {'foo':'bar'},
>                             request=request)
>
> It's slightly longer than the 'ideal' could be, but has some quite big
> advantages:
>
>  * you only have one import whether you want to use RequestContext
>    or Context or both.  And it's an import most people will
>    have already in existing code.
>
>  * you don't have to *learn* a new function name or import
>
>  * in the context of the tutorial, it works very well - no
>    new import to add, just a small change which can be explained
>    without even going into how RequestContext works or that
>    it even exists.
>
>  * 'render_to_response' is nice and explicit, and it's very
>    difficult to shorten it without losing that.
>
> Given where we are right now, I think it's the best option so far.
>
> Comments?
>
> Luke
>
> --
> You meet a lot of smart guys with stupid wives, but you almost
> never meet a smart woman with a stupid husband. (Erica Jong)
>
> Luke Plant ||http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
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: Dumber email validation

[Tim Chase]

> 1) If we encourage people to write their own regex if they want
> tighter email validation, we run the risk that users will
> inadvertently introduce the same bug that we have just fixed. 

Russell raises my biggest concern with this proposal.  There are 
a lot of smart folks in the Django-Developers end of things that 
can cobble together a pretty legit regexp that covers the 
majority of cases with no horrific DOS cases (e.g. last security 
issue).

I've seen the regexps created by people who don't comprehend them 
and it's UGLY.  This proposal basically throws those people to 
the wolves.

I'd much rather Django provided an email field that got most of 
the way and let regexp-understanding users tweak if needed.  But 
I'd hate to see somebody opening themselves to email addresses like

   bad_stuff()@wherever.space space.&

or

   f...@domain.tld\x0a\0x0dfrom: s...@spammer.spam\x0a\0x0dto: 
s...@spimmer.spim\x0a\x0d\x0a\x0dspam, spam, spam!

which can (without added caution) inject headers into sent-mail.

My initial candidate is ticket #12005, though it merely 
re.VERBOSE's the original and tweaks the domain portion to meet 
an internal need.  Some changes on the stuff before the "@" might 
make it more "relaxed" (if not RFC-compliant-ish) while keeping 
out some of the badness.

-tim




--~--~-~--~~~---~--~~
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: Dumber email validation

[Chris Adams]

On Oct 10, 9:35 am, James Bennett  wrote:
> So what I'd like to propose is that EmailField essentially check that
> the value contains an '@', and a '.' somewhere after it. This will
> cover most addresses that are likely to be in actual use, and various
> confirmation processes can be used to rule out any invalid addresses
> which happen to slip through that.

Good idea - every real project I've had where this became an issue had
to switch to some sort of actual mail-based validation system
(confirmation, live MX connection, etc.). Adding doc links about email
validation tools would be better because it'd establish that this is
something which deserves some thought if you rely on email addresses.

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

shortcut proposal

[Luke Plant]

Hi all,

As a consequence of the proposed CSRF changes, we brought up wanting 
to add a shortcut like render_to_response that uses RequestContext, as 
a refinement, but didn't decide on anything.  Ideally, we would have 
something as short as this:

 return render(request, "template_name.html", {'foo':'bar'})

Currently you can do this:

 return render_to_response("template_name.html", {'foo':'bar'},
 context_instance=RequestContext(request))

This is a bit cumbersome, especially with the need to import 
RequestContext as well as render_to_response.  My proposal: add 
'request' as a keyword argument to this same function:

 return render_to_response("template_name.html", {'foo':'bar'},
request=request)

It's slightly longer than the 'ideal' could be, but has some quite big 
advantages:

 * you only have one import whether you want to use RequestContext
   or Context or both.  And it's an import most people will 
   have already in existing code.

 * you don't have to *learn* a new function name or import

 * in the context of the tutorial, it works very well - no
   new import to add, just a small change which can be explained
   without even going into how RequestContext works or that
   it even exists.

 * 'render_to_response' is nice and explicit, and it's very 
   difficult to shorten it without losing that.

Given where we are right now, I think it's the best option so far.

Comments?

Luke

-- 
You meet a lot of smart guys with stupid wives, but you almost 
never meet a smart woman with a stupid husband. (Erica Jong)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Tobias McNulty]

On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss  wrote:
> I'm trying to avoid having two incompatible messaging systems in
> Django. I agree that linking messages to sessions makes more sense
> than linking them to users [1], but we can't just remove the user
> messages API outright. I'd like a good transition strategy, so it
> seems the best way would be to keep the user messages API, but switch
> it to use session messages under the hood.

I know a solution like this was attempted and then abandoned earlier
in the ticket history.

Chris, do you have any wisdom to share about this?  I expect it may be
complicated because I can't think of a clean way to get the current
request (and hence the session messages variable) inside the User
model.

Maybe I'm missing something.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

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

Re: Session/cookie based messages (#4604)

[Tobias McNulty]

On Thu, Oct 15, 2009 at 5:45 AM, Tai Lee  wrote:
> My personal bike shed is named "alerts", but other than that I have
> nothing to add that hasn't already been mentioned. I've been using
> django-notify for a while now, and think it's great. Can't wait to see
> something like it make it's way into core.

That's an option.  It's short and doesn't conflict with anything that
I know of.  I added a section to the wiki with potential app names:

http://code.djangoproject.com/wiki/SessionMessages#PotentialAppNames
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

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

Re: Status of the #6904 ticket (case insensitive sort in dictsort)

[Waylan Limberg]

On Thu, Oct 15, 2009 at 7:44 AM, Douglas Soares de Andrade
 wrote:
>
> Hi all,
>
> What is the status of the following ticket ?
>
> http://code.djangoproject.com/ticket/6904
>

Well, the "Triage Stage" is currently set at "Design decision needed"
which means that it's waiting for a core dev to review the ticket and
either accept or reject it.

> I just had this issue in Django 1.1 and i totally agree with mathwizard
> said.

I don't - and I just posted a comment to the ticket explaining why. If
you (or anyone) wants case-insensitive sorting, just create your own
custom filter that does just that. You could even copy the built-in
filter to your own project/app and use it with a one or two line
change.

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

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

Status of the #6904 ticket (case insensitive sort in dictsort)

[Douglas Soares de Andrade]

Hi all,

What is the status of the following ticket ?

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

I just had this issue in Django 1.1 and i totally agree with mathwizard 
said.

Thanks a lot

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

[Vinay Sajip]

On Oct 15, 8:21 am, Ivan Sagalaev  wrote:
> 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

That may be true if you're a Django user, but for a Django developer
working on Django internals, logging can be a good way of diagnosing
problems which could occur anywhere in the system. So the more
coverage, the better.

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

Again, a logging handler which uses ORM might be fine for many
scenarios, but if there's a problem with the ORM system itself you'd
probably want to diagnose it using file-based handlers.

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

Try out my patch on ticket #12012. I'm about to update it to show
three places where you can hook into Django initialization -
Settings.__init__, pre app/model loading and post app/model loading.
My test will demonstrate initialization of logging at the first hook
point, then capture of the class_prepared signal in pre app/model
loading so that model loading can be watched, then post app/model
loading to show that you can use models in the hooked code.

Regards,

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

LazyObject fix - tiny backwards incompatible change

[Luke Plant]

Hi all,

There is a bit of cruft in LazyObject that I'd like to fix - 
'get_all_members'.  This seems to be left over from before it got 
separated from LazySettings.  The method is *only* needed to support 
introspection, which is usually only used from the interactive prompt.

There is a much better way of doing it - implement the __members__ 
property and the __dir__() method.  This is the standard and future 
compatible way.

I'll need to fix the few instances of where LazyObject is subclassed 
in Django itself.

If anyone else has subclassed LazyObject, from now on the 
'get_all_members' method of wrapped objects will be ignored.  In most 
cases, this will have no effect, because the default __dir__() will do 
the right thing.  

In exceptional cases (where the wrapped object implements 
__getattr__()), introspection won't return all the attributes that it 
should.

Upgrading is easy - if your wrapped object does not implement 
__getattr__(), just remove 'get_all_members()'.  If it does, replace 
'get_all_members' with '__dir__', and if using Python < 2.6, add:

__members__ = property(lambda self: self.__dir__())

Any objections to this? I can only imagine that it will affect 
interactive usage at the Python prompt in a few obscure cases, if 
anything. But I could have missed something.

Luke

-- 
You meet a lot of smart guys with stupid wives, but you almost 
never meet a smart woman with a stupid husband. (Erica Jong)

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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: lazy auth context processor

[Luke Plant]

On Wednesday 14 October 2009 16:39:31 Luke Plant wrote:
> On Wednesday 14 October 2009 15:54:25 Russell Keith-Magee wrote:
> > >  * the output of {{ user }} in a template will be different.  I
> > > think this is acceptable, because only things like {{
> > > user.username }} are actually useful, apart from when
> > > debugging.
> >
> > I disagree. User.__unicode__() returns self.username, so {{ user
> > }} is a potentially useful (albeit non-specific) rendering
> > technique for user.
> 
> OK, I'll fix that.  I had thought that it returned
>  "", but that's repr(), not unicode().

Just to point out, to anyone who cares or gets confused by my patch:

There was a whole bunch of confusion in my original post.  The output 
of {{ user }} was never actually threatened.

I was mixing up unicode/repr/str in my testing, and assuming that they 
would work the same way.  LazyObject as it currently stands [1] will 
proxy __unicode__ methods automatically, but not __repr__ and __str__, 
although it does not have any special casing for any of them.  This is 
due to the fact that 'object' does not provide an implementation of 
__unicode__, but does for the other two, and __getattr__ is only 
triggered when that implementation is not found.

We should probably add that special casing for at least str, possible 
unicode.

Luke

[1] 
http://code.djangoproject.com/browser/django/trunk/django/utils/functional.py?rev=9945#L255

-- 
You meet a lot of smart guys with stupid wives, but you almost 
never meet a smart woman with a stupid husband. (Erica Jong)

Luke Plant || http://lukeplant.me.uk/

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

Re: Proposal: Allow LOGIN_URL to be a callable

[Jonathan Lukens]

+1

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

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

Re: Session/cookie based messages (#4604)

[Tai Lee]

On Oct 14, 10:45 am, Tobias McNulty  wrote:
>
> Okay, let's pick something other than 'messages' and stick to it.  I'm
> fine with "notifications", "notices", and maybe even "notes", but the
> last one is a little ambiguous.  Other ideas?

My personal bike shed is named "alerts", but other than that I have
nothing to add that hasn't already been mentioned. I've been using
django-notify for a while now, and think it's great. Can't wait to see
something like it make it's way into core.

Cheers.
Tai.

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