Changes by Matt Giuca :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue8987>
___
___
Python-bugs-list mailing list
Unsubscri
Matt Giuca added the comment:
Thanks for doing that, Senthil.
--
___
Python tracker
<http://bugs.python.org/issue1712522>
___
___
Python-bugs-list mailin
Matt Giuca added the comment:
>From http://mail.python.org/pipermail/python-checkins/2010-July/095350.html:
> Looking at the issue (which in itself was quite old), you could as well
> have fixed the robotparser module instead.
It isn't an issue with robotparser. The original rep
Matt Giuca added the comment:
> Well, isn't it a new feature you're adding?
You had a function which raised a confusing and unintentional KeyError when
given non-ASCII Unicode input. Now it doesn't. That's the bug fix part.
What I assume you're referring to a
Matt Giuca added the comment:
> I think everyone assumed that the parameter should be a "str" object
> and nothing else. Apparently some people used it accidentally with
> some unicode strings and it "worked" until these strings contained
> non-ASCII characters.
Matt Giuca added the comment:
OK sure, there are some other things broken, but they are mostly not dealing
with string data, but binary data (for example, zlib expects a sequence of
bytes, not characters).
Just one quick point:
> urllib.urlretrieve("file:///tmp/hé")
> U
Matt Giuca added the comment:
If you're going the way of option 2, I would strongly advise against relying on
the KeyError. The fact that a KeyError is raised by urllib.quote is not part of
it's specification, it's a bug/quirk in the implementation (which is now
unlikely to
Matt Giuca added the comment:
OK, I finally had time to review this issue again.
Firstly, granted the original fix broke a test case, shouldn't we figure out
why it broke and fix it, rather than just revert the change and continue
relying on this tenuous assumption? Surely it's be
101 - 108 of 108 matches
Mail list logo
