Hi,
I have attached the ported autoescape patches (without the admin part) to
ticket #2359. I didn't bother to simplify the proxy thing (perhaps another
day). It had a bit of testing and passed the django tests, but porting my
application to unicode is more effort than I thought. I wasn't able to
On Fri, 2007-05-25 at 12:43 +0200, Michael Radziej wrote:
[...]
> I had another problem with force_unicode: It would turn
> any SafeString into an unsafe Unicode. I was not
> able to overwrite SafeString.__unicode__ (python seems
> not to use __unicode__() when you call unicode() with an
> encodin
On Fri, May 25, Malcolm Tredinnick wrote:
> Oh! I'd forgotten that guy was still there. :-(
Fine. I had absolutely no idea why this was there ;-)
I had another problem with force_unicode: It would turn
any SafeString into an unsafe Unicode. I was not
able to overwrite SafeString.__unicode__ (py
On Fri, 2007-05-25 at 19:53 +1000, Malcolm Tredinnick wrote:
> On Fri, 2007-05-25 at 11:32 +0200, Michael Radziej wrote:
> > Hi Malcolm,
> >
> > I'm having a bit of a problem with a strange autoescape test,
> > i.e. filter-syntex18 (taken over from templates).
> >
> > The test uses a weird class
On Fri, 2007-05-25 at 11:32 +0200, Michael Radziej wrote:
> Hi Malcolm,
>
> I'm having a bit of a problem with a strange autoescape test,
> i.e. filter-syntex18 (taken over from templates).
>
> The test uses a weird class:
>
> class UnicodeInStrClass:
> "Class whose __str__ returns a Unicod
Hi Malcolm,
I'm having a bit of a problem with a strange autoescape test,
i.e. filter-syntex18 (taken over from templates).
The test uses a weird class:
class UnicodeInStrClass:
"Class whose __str__ returns a Unicode object."
def __str__(self):
return u'ŠĐĆŽćžšđ'
Well ... some
By the way, I'm currently porting the autoescape patch to the unicode
branch; should be done sometime today, and I'll report back.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Compa
Ok, thanks for your replies (and your work on django) and sorry for
your time. (And I looked at the auto-escape patch, I "only" didn't
apply it and didn't think about it sufficiently.)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
On Thu, 2007-05-24 at 11:46 +, pm13 wrote:
>
> Ivan Sagalaev napsal:
> > pm13 wrote:
> > > I noted that you would like to implement auto-escaping. It will mean
> > > third dimension of potential problems with strings.
> >
> > Why that? Unicode branch is designed to work with byte strings only
On Thu, 2007-05-24 at 04:07 -0700, pm13 wrote:
> I noted that you would like to implement auto-escaping. It will mean
> third dimension of potential problems with strings. What about to
> integrate this patch to the unicode-branch and to disclose all bugs at
> once?
This would not be a good idea.
Ivan Sagalaev napsal:
> pm13 wrote:
> > I noted that you would like to implement auto-escaping. It will mean
> > third dimension of potential problems with strings.
>
> Why that? Unicode branch is designed to work with byte strings only for
> backward compatibility, all new code should use unicod
pm13 wrote:
> I noted that you would like to implement auto-escaping. It will mean
> third dimension of potential problems with strings.
Why that? Unicode branch is designed to work with byte strings only for
backward compatibility, all new code should use unicode everywhere.
Escaping is just a
I started using unicode-branch. Thank you very much for your work - I
had many problems with strings in django but they are solved now.
I had some difficulties with the change (and I submitted some tickets
with patches). There are complex interactions - unicode vs. non-
unicode strings and lazy
13 matches
Mail list logo
