> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
M> From what I've read on the web about the Python Unicode
M> implementation we have one of the better ones compared to other
M> languages implementations and their choices and design
M> decisions.
Yes, indeed!
Speaking-as-
James Y Knight wrote:
> Your point would be much easier to stomach if the "str" type could
> *only* hold 7-bit ASCII.
why? strings are not mutable, so it's not like an ASCII string will suddenly
sprout
non-ASCII characters. what ends up in a string is defined by the string
source. if
you can
On Oct 3, 2005, at 3:47 PM, Fredrik Lundh wrote:
> Antoine Pitrou wrote:
>
>
If I have an unicode string containing legal characters greater
than
0x7F, and I pass it to a function which converts it to str, the
conversion fails.
>>>
>>> so? if it does that, it's not unico
Antoine> If an stdlib function returns an 8-bit string containing
Antoine> non-ascii data, then this string used in unicode context incurs
Antoine> an implicit conversion, which fails.
Such strings should be converted to Unicode at the point where they enter
the application. That's
Martin Blais wrote:
> On 10/3/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
If that's how things were designed, then Python's entire standard
brary (not to mention third-party libraries) is not "unicode safe" -
to quote your own words - since many functions may return 8-bit strings
>
On 10/3/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > > If that's how things were designed, then Python's entire standard
> > > brary (not to mention third-party libraries) is not "unicode safe" -
> > > to quote your own words - since many functions may return 8-bit strings
> > > containing n
Antoine Pitrou wrote:
> To which you apparently didn't read my answer, that is:
> you can never be sure that a variable containing something which
> is /semantically/ textual (*) will never contain anything other than
> ASCII text.
That is simply not true. There are variables that is semantically
At 10:38 PM 10/3/2005 +0200, Antoine Pitrou wrote:
>To which you apparently didn't read my answer, that is:
>you can never be sure that a variable containing something which
>is /semantically/ textual (*) will never contain anything other than
>ASCII text. For example raw_input() won't tell you tha
> > If that's how things were designed, then Python's entire standard
> > brary (not to mention third-party libraries) is not "unicode safe" -
> > to quote your own words - since many functions may return 8-bit strings
> > containing non-ascii characters.
>
> huh? first you talk about functions
Antoine Pitrou wrote:
> > > If I have an unicode string containing legal characters greater than
> > > 0x7F, and I pass it to a function which converts it to str, the
> > > conversion fails.
> >
> > so? if it does that, it's not unicode safe.
> [...]
> > what's that has to do with
> > my argument
Hi,
Le lundi 03 octobre 2005 à 20:37 +0200, Fredrik Lundh a écrit :
> > If I have an unicode string containing legal characters greater than
> > 0x7F, and I pass it to a function which converts it to str, the
> > conversion fails.
>
> so? if it does that, it's not unicode safe.
[...]
> what's
Antoine Pitrou wrote:
> > Under the default encoding (and quite a few other encodings), that's true
> > for
> > plain ascii strings and Unicode strings.
>
> If I have an unicode string containing legal characters greater than
> 0x7F, and I pass it to a function which converts it to str, the
> con
Hi,
Josiah:
> > How can you be sure that something that is /semantically textual/ will
> > always remain "pure ASCII" ? That's contradictory, unless your software
> > never goes out of the anglo-saxon world (and even...).
>
> Non-unicode text input widgets.
You didn't understand my statement.
I
13 matches
Mail list logo
