[Webkit-unassigned] [Bug 37765] REGRESSION(57531): the commit-queue still hates Tor Arne Vestbø

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37765





--- Comment #24 from Eric Seidel <eric at webkit.org>  2010-04-18 22:23:37 PST ---
(In reply to comment #22)
> I guess what I was getting at here is that -- following the "decode early"
> mantra -- we might want to have parse_latest_entry_from_file() accept a
> file-like object from codecs.open() rather than a UTF-8 encoded stream.  That
> way parse_latest_entry_from_file() doesn't have to be encoding aware and will
> see only unicode strings.

Hmm... Maybe.  Seems a bit magical.  We'd have to assert that .read() returned
isinstance(unicode) values or something to be sure.

You're right that it would make the code read more like Python 3.0 would. :)

> I only bring this up because this issue will probably come up in more spots as
> we review more of our code.  Any time we define a function that takes a
> file-like object representing text, we'll need to decide if that function
> should take a UTF-8 encoded stream, say, or an encoding-aware stream from
> codecs.

Yes.  And your point is valid.  Not sure how to make that work with StringIO
for unittesting though.  If I remember correctly StringIO(unicode(...)) will
throw exceptions when read() is called.

> (The codecs module blurs the recommendations in the slide show somewhat because
> you can "decode early" while still seeming to handle a stream of bytes.)
> 
> Incidentally, the Python documentation notes that in Python 3, "there is no
> longer any need for using the encoding-aware streams in the codecs module."
> 
> (from
> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit
> )

Thank you. :)  Very helpful comments as always.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.