Oleg Broytmann wrote:
>When I use str(container) instead of repr(comtainer) does Python need to
> guess if I want an unambiguous representation or a printable representation
> of items? I don't think there is a room for guessing - I explicitly said
> str().
But there's no single, obvious way
I think asking every container type to implement str just to ensure
its subobjects are printed correctly is a losing proposition.
It might be possible for repr to take an extra keyword argument
indicating that it is being used in place of string. Then, when it
recurses on subobjects, it should ca
On Thu, Apr 17, 2008 at 01:36:54PM +1200, Greg Ewing wrote:
> Oleg Broytmann wrote:
> > Do I understand it right that str(objects) calls repr() on items to
> > properly quote strings? (str([1, '1']) must give "[1, '1']" as the result).
> > Is it the only reason?
>
> In the case of strings, yes. Mo
Oleg Broytmann wrote:
> Do I understand it right that str(objects) calls repr() on items to
> properly quote strings? (str([1, '1']) must give "[1, '1']" as the result).
> Is it the only reason?
In the case of strings, yes. More generally, there
can be any kind of object in the list, and repr(x)
i
Guido van Rossum wrote:
> The more I think about this, the more I believe that repr() should
> *not* be changed, and that instead we should give people who like to
> see '日本語' instead of '\u1234\u5678\u9abc' other tools to help
> themselves.
This seems to be a rather ASCII-centric way of thinking
On Wed, Apr 16, 2008 at 11:05 AM, Jason Orendorff
<[EMAIL PROTECTED]> wrote:
> There really are two use cases here: a human-readable repr for
> error/warning/log messages; and a machine-readable, always-the-same,
> ASCII-only repr. Users want to be able to tweak the former.
Does machine-readab
[Jason Orendorff]
> Or have str.__repr__() respect per-thread settings, the way decimal
> arithmetic does.
I don't think that's a very compelling example. I have serious issues
with having global or per-thread state that can change the outcome of
repr(); it would make it impossible to write corr
On Tue, Apr 15, 2008 at 10:30 PM, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
> > import unirep
> > print(*map(unirep.russian, objects))
>
> That's okay if the objects are strings, but what about
> non-string objects that contain strings?
>
> We'd need another protocol, such as
Hello. Sorry for being a bit late in the discussion - my sysadmin has
problems setting up our DNS server so I could not send mail.
On Tue, Apr 15, 2008 at 06:07:46PM -0400, Terry Reedy wrote:
> import unirep
> print(*map(unirep.russian, objects))
>
> or even
>
> from unirep import rus_print
>
>
2008/4/16, Michael Urman <[EMAIL PROTECTED]>:
> I'll miss this, as I suspect the case of printing a list of unicode
> strings will be fairly common. Given Unicode identifiers, even print
> locals() could hit this. But perhaps tools for printing better
> summaries of the contents of lists and dic
2008/4/15 Guido van Rossum <[EMAIL PROTECTED]>:
> On Tue, Apr 15, 2008 at 6:10 PM, Michael Urman <[EMAIL PROTECTED]> wrote:
> >The third use, to represent strings unambiguously, is not a major point,
>
> This is very much dependent on who is looking.
>
> > Similarly it's more useful to have '日本
On Tue, Apr 15, 2008 at 6:10 PM, Michael Urman <[EMAIL PROTECTED]> wrote:
> I agree with that this is enoguh. I see two main uses for repr when it
> comes to strings: to put quotes around the contents, and to replace
> control characters with safe representations the interpreter
> understands.
Paul Moore wrote:
> If you don't
> want to change your code, write
>
> from my_repr import my_repr as repr
But repr() itself doesn't do anything -- it just
invokes the __repr__ method of its argument. So
you can't actually accomplish anything by replacing
it, unless your replacement does a lo
Terry Reedy wrote:
> import unirep
> print(*map(unirep.russian, objects))
That's okay if the objects are strings, but what about
non-string objects that contain strings?
We'd need another protocol, such as __unirep__.
--
Greg
___
Python-3000 mailing l
On Tue, Apr 15, 2008 at 7:06 PM, atsuo ishimoto <[EMAIL PROTECTED]> wrote:
> For debugging, I think patch http://bugs.python.org/issue2630 is
> practical enough if error handler of sys.stdout is 'backslashescape'.
>
> If you are Russian and you want to print list of Cyrillic string, you
> can print
2008/4/16, Terry Reedy <[EMAIL PROTECTED]>:
> I suspect the real solution has to be language-community (and even
> programmer) specific, since I expect most people would like the chars they
> know and expect to be unescaped and others left escaped. So, perhaps there
> should be a unirep module
2008/4/16, Guido van Rossum <[EMAIL PROTECTED]>:
>
> So it sounds like we're doomed if we do, and damned if we don't. Or do
> I misunderstand you? Do you have a practical suggestion?
>
For debugging, I think patch http://bugs.python.org/issue2630 is
practical enough if error handler of sys.stdout
On 15/04/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> | So it sounds like we're doomed if we do, and damned if we don't. Or do
> | I misunderstand you? Do you have a practical suggestion?
>
> You understood the same as me.
That's how
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Tue, Apr 15, 2008 at 10:29 AM, Stephen J. Turnbull
| <[EMAIL PROTECTED]> wrote:
| > Guido van Rossum writes:
| > > In Py3k we may be able to do something else though -- instead of
| > > insisting on ASCII we c
On Tue, Apr 15, 2008 at 10:29 AM, Stephen J. Turnbull
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum writes:
> > In Py3k we may be able to do something else though -- instead of
> > insisting on ASCII we could allow a much larger set of characters to
> > be unescaped.
>
> Yes. The implicatio
Guido van Rossum writes:
> A complaint about this would carry more weight when it came from
> someone who actually has to deal with the issue than coming from a
> purely theoretical perspective (unless I'm wrong and you actually read
> Japanese).
This *is* a problem. In my experience a lot o
On Mon, Apr 14, 2008 at 8:04 PM, atsuo ishimoto <[EMAIL PROTECTED]> wrote:
> 2008/4/14, Michael Urman <[EMAIL PROTECTED]>:
>
> > This theory sounds good to me. Should it perhaps also convert Unicode
> > whitespace and control characters (categories Z* and C*)? While these
> > will often still
2008/4/14, Michael Urman <[EMAIL PROTECTED]>:
> This theory sounds good to me. Should it perhaps also convert Unicode
> whitespace and control characters (categories Z* and C*)? While these
> will often still be printable, like \n and \t they may not be
> distinguishable from some number of ASC
2008/4/15, Greg Ewing <[EMAIL PROTECTED]>:
> Guido van Rossum wrote:
>
> > A complaint about this would carry more weight when it came from
> > someone who actually has to deal with the issue
>
>
> It's not a complaint, just something I thought of. If
> Japanese programmers aren't actually bothe
Guido van Rossum wrote:
> A complaint about this would carry more weight when it came from
> someone who actually has to deal with the issue
It's not a complaint, just something I thought of. If
Japanese programmers aren't actually bothered by this,
then I'm not either.
> Another issue is that r
On Sat, Apr 12, 2008 at 5:17 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > We'd
> > need a third form (eek!) that would preserve the string quotes but be
> > more lenient about non-ASCII. Personally, I think some custom loop to
> > print the values is good enough.
>
>
2008/4/13, Greg Ewing <[EMAIL PROTECTED]>:
> I'm not sure what to do about that, though. Maybe some
> sort of locale setting that makes repr() of a string not
> escape chars that fall into some kind of "normal" set
> according to the user's native language?
>
Here's my idea.
repr() cannot con
Greg Ewing canterbury.ac.nz> writes:
>
> It might not be a serious problem when most of the chars in
> the string are ascii, but what about e.g. a Japanese user
> whose strings consist almost entirely of non-ascii, but are
> for the most part what constitutes perfectly readable text
> to them? Th
Guido van Rossum wrote:
> We'd
> need a third form (eek!) that would preserve the string quotes but be
> more lenient about non-ASCII. Personally, I think some custom loop to
> print the values is good enough.
It might not be a serious problem when most of the chars in
the string are ascii, but wh
Thomas Wouters wrote:
> I don't see the value in str(['1', 1, '1, [1]', '1]',
> '\n[1']) giving hard to understand output.
Random data point: Being forced to do some Ruby programming
recently, I found that Ruby does in fact produce just this
sort of ambiguous output when you print a list, and it'
On Fri, Apr 11, 2008 at 5:55 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>str([a, b, c]) currently does a wrong thing if items are non-ascii
> strings - calling repr() on them produces '\XXX' escapes instead of
> a readable representation.
But merely calling str() on the items instead of r
On Fri, Apr 11, 2008 at 02:44:34PM +0200, Thomas Wouters wrote:
> On Wed, Apr 9, 2008 at 6:30 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Apr 09, 2008 at 09:20:56AM -0700, Guido van Rossum wrote:
> > > We
> > > already have repr() if you want unambiguous output; str() is for
> > >
On Wed, Apr 9, 2008 at 6:30 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 09, 2008 at 09:20:56AM -0700, Guido van Rossum wrote:
> > We
> > already have repr() if you want unambiguous output; str() is for
> > pretty output.
>
> BTW, does Python 3000 fix the problem that str(containe
On Wed, Apr 09, 2008 at 09:20:56AM -0700, Guido van Rossum wrote:
> We
> already have repr() if you want unambiguous output; str() is for
> pretty output.
BTW, does Python 3000 fix the problem that str(container) calls repr()
instead of str() for elements in the container?
Oleg.
--
Oleg
34 matches
Mail list logo
