Unicode exception in 'paster shell' (repr versus __repr__)
Dear list,
I'm experiencing a strange encoding error when using 'paster shell' with
Pylons 0.9.7. In my SQLAlchemy objects I define my own __repr__() method to
an ORM-mapped class. Observe:
class VirtualUser(MyOrm):
def __repr__(self):
return uVirtualUser (#%s): Login=%s Email=%s Comment=%s % \
(self.id, self.login, self.email, self.comment)
Now when in 'paster shell' I try to get this object by just typing its name:
In [48]: user
Out[48]: type 'unicode'
VirtualUser (#22): Login=some-user-name email=j...@example.com
Comment=a-cömment-with-speciäl-chäräcters Domain=example.com
---
UnicodeEncodeErrorTraceback (most recent call last)
/home/chaas/projekte/ispwebadmin/ipython console in module()
/usr/lib/pymodules/python2.5/IPython/Prompts.pyc in __call__(self, arg)
549
550 # and now call a possibly user-defined print mechanism
-- 551 manipulated_val = self.display(arg)
552
553 # user display hooks can change the variable to be
stored in
/usr/lib/pymodules/python2.5/IPython/Prompts.pyc in _display(self, arg)
575 return IPython.generics.result_display(arg)
576 except TryNext:
-- 577 return self.shell.hooks.result_display(arg)
578
579 # Assign the default display method:
/usr/lib/pymodules/python2.5/IPython/hooks.pyc in __call__(self, *args, **kw)
139 #print prio,prio,cmd,cmd #dbg
140 try:
-- 141 ret = cmd(*args, **kw)
142 return ret
143 except ipapi.TryNext, exc:
/usr/lib/pymodules/python2.5/IPython/hooks.pyc in result_display(self, arg)
169
170 if self.rc.pprint:
-- 171 out = pformat(arg)
172 if '\n' in out:
173 # So that multi-line strings line up with the left
column of
/usr/lib/python2.5/pprint.pyc in pformat(self, object)
109 def pformat(self, object):
110 sio = _StringIO()
-- 111 self._format(object, sio, 0, 0, {}, 0)
112 return sio.getvalue()
113
/usr/lib/python2.5/pprint.pyc in _format(self, object, stream, indent,
allowance, context, level)
127 self._readable = False
128 return
-- 129 rep = self._repr(object, context, level - 1)
130 typ = _type(object)
131 sepLines = _len(rep) (self._width - 1 - indent - allowance)
/usr/lib/python2.5/pprint.pyc in _repr(self, object, context, level)
193 def _repr(self, object, context, level):
194 repr, readable, recursive = self.format(object, context.copy(),
-- 195 self._depth, level)
196 if not readable:
197 self._readable = False
/usr/lib/python2.5/pprint.pyc in format(self, object, context, maxlevels,
level)
205 and whether the object represents a recursive construct.
206
-- 207 return _safe_repr(object, context, maxlevels, level)
208
209
/usr/lib/python2.5/pprint.pyc in _safe_repr(object, context, maxlevels, level)
290 return format % _commajoin(components), readable, recursive
291
-- 292 rep = repr(object)
293 return rep, (rep and not rep.startswith('')), False
294
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in
position 120: ordinal not in range(128)
So apparently my __repr__() is called but right after that I get the
UnicodeEncodeError exception. The funny thing is that I get the expected
result by calling user.__repr__() but not when calling repr(user):
In [7]: user.__repr__()
Out[7]: u'VirtualUser (#22): Login=some-user-name email=j...@example.com
Comment=a-cömment-with-speciäl-chäräcters Domain=example.com'
In [8]: repr(user)
---
UnicodeEncodeErrorTraceback (most recent call last)
/home/chaas/projekte/ispwebadmin/ipython console in module()
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in
position 120: ordinal not in range(128)
Does anyone have an explanation why foo.__repr__() and repr(foo) makes such
a difference here? Hints welcome.
Cheers
Christoph
signature.asc
Description: OpenPGP digital signature
Re: Unicode exception in 'paster shell' (repr versus __repr__)
W liście Christoph Haas z dnia wtorek 04 sierpnia 2009: Does anyone have an explanation why foo.__repr__() and repr(foo) makes such a difference here? Hints welcome. Shouldn't repr return plain string, not unicode one? When calling .__repr__() directly you just call a method directly. When called by repr() some ipython magic happens, which expects __repr__ to return a string. -- Paweł Stradomski --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
maximizing a list analysis under pylons
This is slightly OT... I need to loop through a bunch of email list subscription transactions ( sub vs unsub actions) and generate a finalized opt-in or opt-out list. Under normal python / perl , I'd just use a 'seen' dict/hash and test for presence. In this situation I'm running inside a Pylons controller , so that code wouldn't scale well -- potentially eating memory and affecting the rest of the app. Can anyone offer a suggestion on how to better approach this? I was thinking that a temporary BDB file could trade off disk-io for memory, but then that could create a lot of io. This is super annoying ( trying to figure out a scalable solution ). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using %(here)s in logging config
On Mon, Aug 3, 2009 at 7:30 PM, Philip Jenveypjen...@underboss.org wrote: On Aug 3, 2009, at 2:41 AM, kochhar wrote: Mike Orr wrote: On Fri, Jul 31, 2009 at 12:05 PM, kochharkochhar...@gmail.com wrote: The file is used in two different ways. Variables are extracted using paste.deploy.loadwsgi.NicerConfigParser, which interpolates %(here)s. Logging configuration is done by logging.config.fileConfig, which doesn't know about interpolation. That's quite non-intuitive. What's the benefit of lumping the configs together if they behave differently? Could NicerConfigParser be used to generate an temporary interpolated version of the config file to give to logging's fileConfig? I'd be happy to write a patch if that's a reasonable fix. fileConfig accepts a set of defaults to pass to ConfigParser, so I've made PasteScript's logging config loader pass 'here' (and also '__file__' which PasteDeploy apparently sets up): http://trac.pythonpaste.org/pythonpaste/changeset/8052 How does that work? The defaults are supposed to be logging.basicConfig arguments, not 'here' and '__file__', which basicConfig doesn't know what to do with. -- Mike Orr sluggos...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using %(here)s in logging config
On Aug 4, 2009, at 11:28 AM, Mike Orr wrote: On Mon, Aug 3, 2009 at 7:30 PM, Philip Jenveypjen...@underboss.org wrote: fileConfig accepts a set of defaults to pass to ConfigParser, so I've made PasteScript's logging config loader pass 'here' (and also '__file__' which PasteDeploy apparently sets up): http://trac.pythonpaste.org/pythonpaste/changeset/8052 How does that work? The defaults are supposed to be logging.basicConfig arguments, not 'here' and '__file__', which basicConfig doesn't know what to do with. No, they're just defaults for ConfigParser. basicConfig isn't involved at all with fileConfig -- Philip Jenvey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Using %(here)s in logging config
Philip Jenvey wrote: On Aug 3, 2009, at 2:41 AM, kochhar wrote: Mike Orr wrote: On Fri, Jul 31, 2009 at 12:05 PM, kochharkochhar...@gmail.com wrote: The file is used in two different ways. Variables are extracted using paste.deploy.loadwsgi.NicerConfigParser, which interpolates %(here)s. Logging configuration is done by logging.config.fileConfig, which doesn't know about interpolation. That's quite non-intuitive. What's the benefit of lumping the configs together if they behave differently? Could NicerConfigParser be used to generate an temporary interpolated version of the config file to give to logging's fileConfig? I'd be happy to write a patch if that's a reasonable fix. fileConfig accepts a set of defaults to pass to ConfigParser, so I've made PasteScript's logging config loader pass 'here' (and also '__file__' which PasteDeploy apparently sets up): http://trac.pythonpaste.org/pythonpaste/changeset/8052 Thanks! Is a new release planned anytime soon? I could track trunk if it's going to be a while. - kochhar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
