On Wed, Aug 24, 2005 at 09:11:18PM +0200, Dieter Maurer wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42
> -0600:
> > The code was fixed by changing
> > the line "header = str(header)" to:
> >
> > if isinstance(header, unicode):
> > hea
The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.
Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42 -0600:
> ...
> Some code may require that str() returns a str instance. In the
> standard library, only one suc
At 10:54 AM 8/23/2005 -0600, Neil Schemenauer wrote:
>On Tue, Aug 23, 2005 at 11:43:02AM -0400, Phillip J. Eby wrote:
> > At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote:
> > >> then of course, one could change ``unicode.__str__()`` to return
> > >> ``self``, itself, which should work. but then
On Tue, Aug 23, 2005 at 05:45:27PM +0200, Wolfgang Lipp wrote:
> i have to revise my last posting -- exporting the new ``str``
> pure-python implementation breaks -- of course! -- as soon
> as ``isinstance(x,str)`` [sic] is used
Right. I tried to come up with a pure Python version so people
could
On Tue, Aug 23, 2005 at 11:43:02AM -0400, Phillip J. Eby wrote:
> At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote:
> >> then of course, one could change ``unicode.__str__()`` to return
> >> ``self``, itself, which should work. but then, why so complicated?
> >
> >I think that may be the right f
i have to revise my last posting -- exporting the new ``str``
pure-python implementation breaks -- of course! -- as soon
as ``isinstance(x,str)`` [sic] is used. right now it breaks
because you can't have a function as the second argument of
``isinstance()``, but even if that could be avoided by ca
At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote:
> > then of course, one could change ``unicode.__str__()`` to return
> > ``self``, itself, which should work. but then, why so complicated?
>
>I think that may be the right fix.
No, it isn't. Right now str(u"x") coerces the unicode object to a
On Tue, Aug 23, 2005 at 10:46:36AM +0200, Wolfgang Lipp wrote:
> one point i don't seem to understand right now is why it says in the
> function definition::
>
> if type(s) is str or type(s) is unicode:
> ...
>
> instead of using ``isinstance()``.
I don't think isinstance() would b
Neil Schemenauer wrote:
> The PEP has been rewritten based on a suggestion by Guido to change
> str() rather than adding a new built-in function. Based on my testing, I
> believe the idea is feasible.
note that this breaks chapter 3 of the tutorial:
http://docs.python.org/tut/node5.html#SECTION
just tested the proposed implementation on a unicode-naive module
basically using
import sys
import __builtin__
reload( sys ); sys.setdefaultencoding( 'utf-8' )
__builtin__.__dict__[ 'str' ] = new_str_function
et voilà, str() calls in the module are rewritten, and
print u'düsseldorf' does
Thomas Heller wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes:
>
>
>>[Please mail followups to [EMAIL PROTECTED]
>>
>>The PEP has been rewritten based on a suggestion by Guido to change
>>str() rather than adding a new built-in function. Based on my
>>testing, I believe the idea is feasible
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> [Please mail followups to [EMAIL PROTECTED]
>
> The PEP has been rewritten based on a suggestion by Guido to change
> str() rather than adding a new built-in function. Based on my
> testing, I believe the idea is feasible. It would be helpful if
> p
neil,
i just intended to worry that returning a unicode object from ``str()``
would break assumptions about the way that 'type definers' like
``str()``, ``int()``, ``float()`` and so on work, but i quickly
realized that e.g. ``int()`` does return a long where appropriate!
since the principle works
13 matches
Mail list logo
