Re: ImportError catching in urlresolvers.py

On Wed, Jun 15, 2011 at 1:31 PM, burc...@gmail.com wrote: > Hi Russell, > > and what do you say about showing call stack properly? > > The problem is not ViewDoesNotExist itself, but throwing away useful > traceback. > > If we do instead: >    import sys >    try: >        

Re: ImportError catching in urlresolvers.py

Hi Russell, and what do you say about showing call stack properly? The problem is not ViewDoesNotExist itself, but throwing away useful traceback. If we do instead: import sys try: self._callback = get_callable(self._callback_str) except ImportError, e: mod_name, _ =

Re: ImportError catching in urlresolvers.py

On Wed, Jun 15, 2011 at 11:51 AM, David Cramer wrote: > This is currently a problem all over in the Django codebase, and I'd > love to see a generic/reusable approach at solving this everywhere. We already have a generic/reusable approach -- it's just not used everywhere that

Re: ImportError catching in urlresolvers.py

This is currently a problem all over in the Django codebase, and I'd love to see a generic/reusable approach at solving this everywhere. On Jun 14, 1:19 pm, Michael Blume wrote: > In RegexURLPattern._get_callback, we attempt to fetch the callable named by > the URL pattern,

Re: Ability to change dismissRelatedLookupPopup on my own callback function

I create ticket and upload patch. https://code.djangoproject.com/ticket/16260 On Tue, Jun 14, 2011 at 5:18 PM, Alex Kamedov wrote: > Thank you for sharing good solution, Gregor! > Your solution works great if you has one related lookup. If you need work > with some related

ImportError catching in urlresolvers.py

In RegexURLPattern._get_callback, we attempt to fetch the callable named by the URL pattern, and catch a possible ImportError if this fails. If so, we raise ViewDoesNotExist. try: self._callback = get_callable(self._callback_str) except ImportError, e:

Re: WSGIRequest._stream.read() blocking

> Isn't this the same bug as and ? Yes. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

Re: WSGIRequest._stream.read() blocking

Thanks Roberto, We had UWSGI 0.9.6.8 installed first. Now I did an upgrade to 0.9.8 and now everything works perfect. Thanks a lot for the quick response. On 14 juin, 15:00, Roberto De Ioris wrote: > Il giorno 14/giu/2011, alle ore 14.54, Jonathan Slenders ha scritto: > > >

Re: WSGIRequest._stream.read() blocking

Hi Jonathan, Isn't this the same bug as and ? Best regards, -- Aymeric Augustin. 2011/6/14 Jonathan Slenders > if I replace: > > > if type(socket._fileobject) is type and

Re: WSGIRequest._stream.read() blocking

Il giorno 14/giu/2011, alle ore 14.54, Jonathan Slenders ha scritto: > Hi all, > > > Using WSGI on production environment: > > In django.core.handlers.wsgi.py is a clear notice that wsgi.input, > which can be an instance of socket._fileobject will hang when reading > past the available count.

Re: WSGIRequest._stream.read() blocking

if I replace: > if type(socket._fileobject) is type and > isinstance(self.environ['wsgi.input'], socket._fileobject): by: > if True in django.core.handlers.wsgi.py Then, everything works perfect, so it has to be in this check. -- You received this message because you are subscribed to the

WSGIRequest._stream.read() blocking

Hi all, Using WSGI on production environment: In django.core.handlers.wsgi.py is a clear notice that wsgi.input, which can be an instance of socket._fileobject will hang when reading past the available count. In my case, wsgi.input appears to be of the type 'file', so the following test fails,

Re: Logging configuration and handle_uncaught_exception

On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip wrote: > On Jun 10, 2:05 pm, Matt Bennett wrote: > >> Is there a reason the call to logger.error can't come before we return >> the technical_500_response when DEBUG=True? It seems to me that the >> debug

Re: Ability to change dismissRelatedLookupPopup on my own callback function

Thank you for sharing good solution, Gregor! Your solution works great if you has one related lookup. If you need work with some related fields you must write more javascript code whitch looks like mankey patching. On Tue, Jun 14, 2011 at 4:29 PM, Gregor Müllegger wrote: >

Re: RFC: Templatetag API for form rendering

Hi, Le 22/05/2011 22:21, Gregor Müllegger a écrit : {% renderform my_form hidden "honeypot" %} Render all fields but outputs the my_form.honeypot field as a hidden field. If one wants to force a field to be hidden, wouldn't it be better to use a "hidden" widget? Why provide a "hidden"

Re: RFC: Templatetag API for form rendering

I'm not sure yet, if it's worth the extra {% formdefaults %} tag. Ofcourse it > prevents template authors from excidentally overriding defaults, but I think > who will use these utilities must know about these implications anyway. It's > somehow just reflecting the behaviour of a python module

Re: RFC: Templatetag API for form rendering - Second Edition

Le 03/06/2011 16:58, Gregor Müllegger a écrit : {% formerrors %} Will it use duck typing? rather than testing Form or Field or ErrorList or ErrorDict subclasses. Drawback: more work needed since some refactoring of Form, BoundField, ErrorList and ErrorDict may be required. Advantage:

Re: RFC: Templatetag API for form rendering

Le 22/05/2011 22:21, Gregor Müllegger a écrit : {% renderform my_form %} Another suggest from formrenderingtools... Can we consider that "form" is the naming convention for form context variables? * generic views use "form" * there is usually only one form in a view If "form" can be

Re: RFC: Templatetag API for form rendering

Le 23/05/2011 00:21, Carl Meyer a écrit : Just had a quick conversation with Gregor and Chris Beaven on IRC; based on a comment of Chris', we discussed the possibility of ditching the {% formlayout %} tag in favor of specifying the layout as an argument to the {% form %} block tag. E.g. instead

Re: RFC: Templatetag API for form rendering

Le 24/05/2011 16:35, Gregor Müllegger a écrit : This is not yet defined in detail. I would suggest a schema like: forms/layouts//.html Resulting in templates for the layout "table" like: forms/layouts/table/row.html forms/layouts/table/label.html

Re: RFC: Templatetag API for form rendering - Second Edition

Le 03/06/2011 16:58, Gregor Müllegger a écrit : Hi, this is the second RFC regarding template form rendering API/syntax. The first one defined how a complete form or a subset of fields will be rendered. I'm now proposing more tags to render more details like only the label of a form field.

Re: Ability to change dismissRelatedLookupPopup on my own callback function

Hi I needed to do the same in my own projects, however I just decorated the functions which I wanted to modify. Like: original_dismissRelatedLookupPopup = window.dismissRelatedLookupPopup; window.dismissRelatedLookupPopup = function () { // put your own code here ...

Re: Customizable serialization. (Finally?)

Hi ! Looks like a great idea to me. I had already proposed something similar when there were talks for implementing this for SOC. Like I had said in this thread, I have already implemented something that works a similar way as what you propose :