Re: gettext and _: what changed?
Wow... you guys are incredible! Of course I don't mind waiting... I was expecting 3-6 months! On Jun 21, 5:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2007-06-21 at 07:14 +, Michael wrote: > > Thanks Malcolm. > > > I'm assuming that the unicode branch is going to be merged soon? Or > > otherwise, is it worth me submitting a patch to your ticket with: > > > from django.utils.translation import gettext as _ > > > added to all files that use _()? (or maybe there are other > > complications.) > > The Oracle branch is going first (and that's waiting for me to merge it, > I guess) and then I'll merge the Unicode branch a week later (to give > the first merge time to settle down). So within a week or two it should > be merged. I don't really want to have to mess around with a big-ish > change like this to trunk and then resolving all the conflicts on the > unicode branch (where ugettext() is used by default), so if you could > just put up with the current state of affairs a little bit longer, I'd > really appreciate it. > > 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 -~--~~~~--~~--~--~---
Re: gettext and _: what changed?
On Thu, 2007-06-21 at 07:14 +, Michael wrote: > Thanks Malcolm. > > I'm assuming that the unicode branch is going to be merged soon? Or > otherwise, is it worth me submitting a patch to your ticket with: > > from django.utils.translation import gettext as _ > > added to all files that use _()? (or maybe there are other > complications.) The Oracle branch is going first (and that's waiting for me to merge it, I guess) and then I'll merge the Unicode branch a week later (to give the first merge time to settle down). So within a week or two it should be merged. I don't really want to have to mess around with a big-ish change like this to trunk and then resolving all the conflicts on the unicode branch (where ugettext() is used by default), so if you could just put up with the current state of affairs a little bit longer, I'd really appreciate it. 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 -~--~~~~--~~--~--~---
Re: gettext and _: what changed?
Thanks Malcolm.
I'm assuming that the unicode branch is going to be merged soon? Or
otherwise, is it worth me submitting a patch to your ticket with:
from django.utils.translation import gettext as _
added to all files that use _()? (or maybe there are other
complications.)
Cheers,
Michael.
On Jun 21, 4:38 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-06-21 at 04:49 +, Michael wrote:
>
> > On May 11, 7:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > wrote:
> > > No. Prior to 1.0 we are going to remove the implicit and automatic
> > > aliasing ofgettext() to _() throughout the code anyway. It's a bit of a
> > > Python design wart -- i.e. they *really* didn't think it through. The
> > > problem is that if you rely on the it always being in builtins, doctests
> > > (and interactive shell work) break. In fact, I'm pretty sure that's
> > > somewhat the cause of the problem you're seeing. Remember that _ is used
> > > as "the last result" in the Python interactive prompt.
>
> > > So we have an open ticket (#2920) to remove it everywhere in our
> > > internal code and not install it in builtins. People will need to import
> > > it explicitly, which will also force them to think about whether they
> > > really meangettext() or gettext_lazy().
>
> > It seems that the implicit use of _() within the Django's current
> > admin interface is breaking unit tests for my own views (I'm guessing
> > from the errors below that its related to the use of the {% url url-
> > name %} tag). Error shown below. Note that if I add:
>
> > from django.utils.translation import gettext as _
>
> > to the relevant admin file (in this case, contrib/admin/views.doc.py)
> > then the tests run as per normal. Everything is fine through a browser
> > on the test server.
>
> > Does anyone know if there's another way to fix this without modifying
> > the trunk django checkout (as obviously all the tests break when
> > someone else runs them with a fresh checkout of django).
>
> That's the recommended fix at the moment.
>
> Once the unicode branch is merged into trunk (probably as part of the
> merge), we will remove _() from automatic installation into builtins
> altogether. It doesn't really make sense to default to gettext() in a
> unicode world and developers should be thinking about whether they
> should be using ugettext or gettext or ugettext_lazy or some other
> method -- one version isn't always correct. It will also fix problems at
> the interactive prompt (where _ is overloaded) and in doctests (for the
> same reason)
>
> 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
-~--~~~~--~~--~--~---
Re: gettext and _: what changed?
On Thu, 2007-06-21 at 04:49 +, Michael wrote:
>
>
> On May 11, 7:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > No. Prior to 1.0 we are going to remove the implicit and automatic
> > aliasing ofgettext() to _() throughout the code anyway. It's a bit of a
> > Python design wart -- i.e. they *really* didn't think it through. The
> > problem is that if you rely on the it always being in builtins, doctests
> > (and interactive shell work) break. In fact, I'm pretty sure that's
> > somewhat the cause of the problem you're seeing. Remember that _ is used
> > as "the last result" in the Python interactive prompt.
> >
> > So we have an open ticket (#2920) to remove it everywhere in our
> > internal code and not install it in builtins. People will need to import
> > it explicitly, which will also force them to think about whether they
> > really meangettext() or gettext_lazy().
>
> It seems that the implicit use of _() within the Django's current
> admin interface is breaking unit tests for my own views (I'm guessing
> from the errors below that its related to the use of the {% url url-
> name %} tag). Error shown below. Note that if I add:
>
> from django.utils.translation import gettext as _
>
> to the relevant admin file (in this case, contrib/admin/views.doc.py)
> then the tests run as per normal. Everything is fine through a browser
> on the test server.
>
> Does anyone know if there's another way to fix this without modifying
> the trunk django checkout (as obviously all the tests break when
> someone else runs them with a fresh checkout of django).
That's the recommended fix at the moment.
Once the unicode branch is merged into trunk (probably as part of the
merge), we will remove _() from automatic installation into builtins
altogether. It doesn't really make sense to default to gettext() in a
unicode world and developers should be thinking about whether they
should be using ugettext or gettext or ugettext_lazy or some other
method -- one version isn't always correct. It will also fix problems at
the interactive prompt (where _ is overloaded) and in doctests (for the
same reason)
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
-~--~~~~--~~--~--~---
Re: gettext and _: what changed?
On May 11, 7:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> No. Prior to 1.0 we are going to remove the implicit and automatic
> aliasing ofgettext() to _() throughout the code anyway. It's a bit of a
> Python design wart -- i.e. they *really* didn't think it through. The
> problem is that if you rely on the it always being in builtins, doctests
> (and interactive shell work) break. In fact, I'm pretty sure that's
> somewhat the cause of the problem you're seeing. Remember that _ is used
> as "the last result" in the Python interactive prompt.
>
> So we have an open ticket (#2920) to remove it everywhere in our
> internal code and not install it in builtins. People will need to import
> it explicitly, which will also force them to think about whether they
> really meangettext() or gettext_lazy().
It seems that the implicit use of _() within the Django's current
admin interface is breaking unit tests for my own views (I'm guessing
from the errors below that its related to the use of the {% url url-
name %} tag). Error shown below. Note that if I add:
from django.utils.translation import gettext as _
to the relevant admin file (in this case, contrib/admin/views.doc.py)
then the tests run as per normal. Everything is fine through a browser
on the test server.
Does anyone know if there's another way to fix this without modifying
the trunk django checkout (as obviously all the tests break when
someone else runs them with a fresh checkout of django).
Thanks in advance for any tips!
Error msg:
==
ERROR: testHomePageUnAuth (apps.localgroups.tests.HomePage)
--
Traceback (most recent call last):
File "/home/michael/Programming/cyiada/apps/localgroups/tests.py",
line 199, in testHomePageUnAuth
response = self.client.get('/')
File "/usr/lib/python2.5/site-packages/django/test/client.py", line
200, in get
return self.request(**r)
File "/usr/lib/python2.5/site-packages/django/core/handlers/
base.py", line 77, in get_response
response = callback(request, *callback_args, **callback_kwargs)
File "/home/michael/Programming/cyiada/apps/localgroups/views.py",
line 27, in groupmap
context_instance=RequestContext(request))
File "/usr/lib/python2.5/site-packages/django/shortcuts/
__init__.py", line 10, in render_to_response
return HttpResponse(loader.render_to_iter(*args, **kwargs))
File "/usr/lib/python2.5/site-packages/django/template/loader.py",
line 124, in render_to_iter
return t.iter_render(c)
File "/usr/lib/python2.5/site-packages/django/test/utils.py", line
19, in instrumented_test_render
return self.nodelist.render(context)
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 737, in render
return ''.join(self.iter_render(context))
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 758, in iter_render
for chunk in node.iter_render(context):
File "/usr/lib/python2.5/site-packages/django/template/
loader_tags.py", line 82, in iter_render
return compiled_parent.iter_render(context)
File "/usr/lib/python2.5/site-packages/django/test/utils.py", line
19, in instrumented_test_render
return self.nodelist.render(context)
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 737, in render
return ''.join(self.iter_render(context))
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 758, in iter_render
for chunk in node.iter_render(context):
File "/usr/lib/python2.5/site-packages/django/template/
loader_tags.py", line 82, in iter_render
return compiled_parent.iter_render(context)
File "/usr/lib/python2.5/site-packages/django/test/utils.py", line
19, in instrumented_test_render
return self.nodelist.render(context)
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 737, in render
return ''.join(self.iter_render(context))
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 758, in iter_render
for chunk in node.iter_render(context):
File "/usr/lib/python2.5/site-packages/django/template/
loader_tags.py", line 23, in iter_render
for chunk in self.nodelist.iter_render(context):
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 758, in iter_render
for chunk in node.iter_render(context):
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 769, in iter_render
raise wrapped
TemplateSyntaxError: Caught an exception while rendering: 'Membership'
object is not callable
Original Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/django/template/__init__.py",
line 758, in iter_render
for chunk in node.iter_render(context):
File "/usr/lib/python2.5/site-packages/django/template/
defaulttags.py", line 356, in iter_render
return (reverse(self.view_name, args=args,
Re: gettext and _: what changed?
> No. Prior to 1.0 we are going to remove the implicit and automatic > aliasing of gettext() to _() throughout the code anyway. It's a bit of a > Python design wart -- i.e. they *really* didn't think it through. The > problem is that if you rely on the it always being in builtins, doctests > (and interactive shell work) break. In fact, I'm pretty sure that's > somewhat the cause of the problem you're seeing. Remember that _ is used > as "the last result" in the Python interactive prompt. ok, thanks again. But I can say the problem is not just the interactive shell. I resorted to use it becouse the code that always worked gave me that exact error. Anyhow I will just import explicitely. sandro *:-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: gettext and _: what changed?
On Fri, 2007-05-11 at 02:13 -0700, sandro dentella wrote:
> Hi,
>
> here again...
>
> I think that this is an error, at least again a different behaviour
> compared to version of some weeks ago (r4871)
>
>
> ## english version gives no problem
> (Pdb) print "New Ticket #%(id)s '%(title)s' for project %(project)s" %
> (Item(instance))
> New Ticket #3 'test 3' for project jungle
>
> ## translated version raise TypeError
> (Pdb) _("New Ticket #%(id)s '%(title)s' for project %(project)s")
> *** TypeError: 'Item' object is not callable
>
>
> ## let's take the gettext, not the builtin one
> (Pdb) from django.utils.translation import gettext
> (Pdb) gettext("New Ticket #%(id)s '%(title)s' for project %
> (project)s")
> "Nuovo Ticket #%(id)s '%(title)s' per il progetto %(project)s"
>
> it works!
>
> just for completeness Item is defined as:
>
> class Item(object):
> """ a simple way to turn an instance into a subscriptable obj
> return an object encoded into settings.DEFAULT_CARSET
> """
>
> def __init__(self, obj, enc=settings.DEFAULT_CHARSET):
> self.obj = obj
> self.ENC = enc
>
> def __getitem__(self, name):
> try:
> return getattr(self.obj, name).encode(self.ENC)
> except:
> ## integers and other do not have 'encode' attribute
> return getattr(self.obj, name)
>
> Of course the solution for me is just to import gettext explicitely.
> Should
> I file a ticket for this?
No. Prior to 1.0 we are going to remove the implicit and automatic
aliasing of gettext() to _() throughout the code anyway. It's a bit of a
Python design wart -- i.e. they *really* didn't think it through. The
problem is that if you rely on the it always being in builtins, doctests
(and interactive shell work) break. In fact, I'm pretty sure that's
somewhat the cause of the problem you're seeing. Remember that _ is used
as "the last result" in the Python interactive prompt.
So we have an open ticket (#2920) to remove it everywhere in our
internal code and not install it in builtins. People will need to import
it explicitly, which will also force them to think about whether they
really mean gettext() or gettext_lazy().
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
-~--~~~~--~~--~--~---
