Benjamin Peterson wrote:
What's the status of yield from? There's still a small window open for
a patch to be checked into 3.1's branch. I haven't been following the
python-ideas threads, so I'm not sure if it's ready yet.
The PEP itself seems to have settle down, and is
awaiting a verdict from
With issue 3672 resolved, it is now unnecessary to introduce
an utf-8b codec, since the utf-8 codec will properly report errors
for all byte sequences invalid in UTF-8, including lone surrogates.
Therefore, utf-8b can be implemented solely through the error handler.
Glenn Linderman suggested that
Zooko O'Whielacronx writes:
> However, it is moot because Tahoe is not a new system. It is currently
> at v1.4.1, has a strong policy of backwards-compatibility, and already
> has lots of data, lots of users, and programmers building on top of
> it.
Cool!
Question: is there a way to negotiat
2009/5/3 "Martin v. Löwis" :
> With issue 3672 resolved, it is now unnecessary to introduce
> an utf-8b codec, since the utf-8 codec will properly report errors
> for all byte sequences invalid in UTF-8, including lone surrogates.
> Therefore, utf-8b can be implemented solely through the error hand
Martin v. Löwis v.loewis.de> writes:
>
> Glenn Linderman suggested that the name "python-escape" is not very
> descriptive, so I've changed the name to "utf8b".
If the error handler is supposed to be used for codecs other than utf-8,
perhaps it should renamed something more generic, e.g. "surrog
(I still don't really have net access back after moving house - just
chiming in briefly via my mobile)
Anyway, I think there is one very good reason for NOT defining a multi-
with statement in terms of an existing tuple: it gains us nothing
except speed over contextlib.nested. The whole poin
On Sun, May 3, 2009 at 08:43, Antoine Pitrou wrote:
> Also, if utf8-b is not provided as a codec, will there be an easy way for user
> code to use the same encoding as the IO layer does? (e.g.
> os.fsdecode/os.fsencode)?
I like the idea of fsencode/fsdecode functions, but we need to be
careful de
> That's even nicer. One minor detail though, in the sentence:
>
> "non-decodable bytes >128 will be represented as lone half surrogate"
>
> ">" should be ">=".
Thanks, fixed.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
> If the error handler is supposed to be used for codecs other than utf-8,
> perhaps it should renamed something more generic, e.g. "surrogate-escape"?
Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
it's an algorithm based on 16-bit or 32-bit code points.
> Also, if utf8
On Sun, May 3, 2009 at 10:39 AM, "Martin v. Löwis" wrote:
> > If the error handler is supposed to be used for codecs other than utf-8,
> > perhaps it should renamed something more generic, e.g.
> "surrogate-escape"?
>
> Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
> it'
> > If the error handler is supposed to be used for codecs other than
> utf-8,
> > perhaps it should renamed something more generic, e.g.
> "surrogate-escape"?
>
> Perhaps. However, utf-8b doesn't really have to do anything with utf-8 -
> it's an algorithm based on 16-bit o
On Sun, May 3, 2009 at 1:27 PM, "Martin v. Löwis" wrote:
> > > If the error handler is supposed to be used for codecs other than
> > utf-8,
> > > perhaps it should renamed something more generic, e.g.
> > "surrogate-escape"?
> >
> > Perhaps. However, utf-8b doesn't really have
2009/5/3 Greg Ewing :
> Benjamin Peterson wrote:
>>
>> What's the status of yield from? There's still a small window open for
>> a patch to be checked into 3.1's branch. I haven't been following the
>> python-ideas threads, so I'm not sure if it's ready yet.
>
> The PEP itself seems to have settle
(sent only to python-dev, as I am not a subscriber of tahoe-dev)
Zooko wrote:
> [Tahoe] currently uses utf-8 for its internal storage (note: nothing to
> do with reading or writing files from external sources -- only for
> storing filenames in the decentralized storage system which is
> accessed
14 matches
Mail list logo
