> Yes, I have just tried to return app_iter as str(app_iter[0]) and it
> worked.
> Thanks!
> Now I see that my "200 OK" responses return a list of str() and they
> worked
> perfectly, but...
>
> According to Pylons documentation (
> http://docs.pylonsproject.org/projects/webhelpers/dev/modules/html/builder.html
> )
>
> "literal is a subclass of unicode, so it works with all string methods and
> expressions. The only thing special about it is the .__html__ method,
> which
> returns the string itself. The escape() function follows a simple
> protocol:
> if the object has an .__html__ method, it calls that rather than .__str__
> to
> get the HTML representation. Third-party libraries that do not want to
> import literal (and this create a dependency on WebHelpers) can put an
> .__html__ method in their own classes returning the desired HTML
> representation."
>
> I thought the "literal" object had to be transparent to third-party
> components that expect a string in their input interfaces. And
> CherryPyWSGIServer did the implicit casting pretty well. Is this a
> vendor-specific behaviour not related to pep333 or all wsgi web servers
> should try to implicitly cast incoming iterable to str()?
>
>

It is cherrypy-specific, probably other WSGI servers will do this but in
this way you can potentially return sensible information to the browser (a
lot of object returns memory address or other infos when str is used on
them).

By the way, in your case the best thing (elegant ?) to do would be using
the .__html__ attribute instead of str() casting.

-- 
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to