Hi Eugene,
On Sat, 2007-06-02 at 21:46 +0000, Eugene Morozov wrote:
>
>
> On 24 , 17:06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Hi folks,
> >
> > The unicode branch, [1], is now at a point where it is essentially
> > feature-complete and could do with a bit of heavy testing from the wider
> > community.
> >
> > So if you have some applications that work against Django's current
> > trunk and would like to try them out on the unicode branch, I'd
> > appreciate your efforts. The porting effort should be very minimal
> > (almost zero, in many cases).
>
> Hello,
> I've checked out unicode branch today and immediately found two bugs.
> This code doesn't work:
> def __unicode__(self):
> langs = dict(settings.LANGUAGES)
> return _("%s text of the page %s") % (langs[self.language],
> self.page.url)
>
> (I get TypeError: unsupported operand type(s) for %: '__proxy__' and
> 'tuple')
Just a tip for next time: a bit more information would have been really
useful for working this out: which line gives the exception? What is _()
an alias for? What is the code surrounding this? You are using all sorts
of variables here that could come from anywhere.
After a bit of scratching my head and experimenting, I figured out that
you were saying that
ugettext_lazy("some string %s") % some_variable
is not doing what you expect.
It's probably not a great idea to use ugettext_lazy and then immediately
substitute in variables (using ugettext() would be faster), but we can
probably hack something up (and it will be a hack, because Python
doesn't supply enough information to be able to override the '%'
operator perfectly in these cases) in order to have this work for
ugettext_lazy and gettext_lazy and friends so that they behave more like
strings there.
> The second bug is actually the unicode bug that was present in non-
> unicode django and still persists in unicode branch. Unicode data
> fetched from postgresql using psycopg2 is invalid under some
> circumstances. I'll provide more details when I'll have time.
Please open a ticket when you have the necessary information (don't
report it here, it will just get lost in the traffic) -- nobody has ever
reported this before, that I'm aware of. It sounds very strange -- all
the conversion to unicode is done inside psycopg2 and once it's
converted to a unicode object I'm not sure what "invalid" would mean in
this context -- the data is either converted from whatever PostgreSQL
stores it as or it isn't. So we'll need an example of exactly what is
going wrong to be able to reproduce this. The example should include
what you expect to see and what actually happens.
Thanks for taking the time to test the code. It's appreciated.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
