Any capitalization of "xn--" should be acceptable for the ACE prefix
(see https://tools.ietf.org/html/rfc3490#section-5).
Co-authored-by: Pepijn de Vos <pepijndevos@gmail.com>
Co-authored-by: Erlend E. Aasland <erlend@python.org>
Co-authored-by: Petr Viktorin <encukou@gmail.com>
There was an unnecessary quadratic loop in idna decoding. This restores
the behavior to linear.
This also adds an early length check in IDNA decoding to outright reject
huge inputs early on given the ultimate result is defined to be 63 or fewer
characters.
No detailed change log; just check out the change log for the py3k-pep3137
branch. The most obvious changes:
- str8 renamed to bytes (PyString at the C level);
- bytes renamed to buffer (PyBytes at the C level);
- PyString and PyUnicode are no longer compatible.
I.e. we now have an immutable bytes type and a mutable bytes type.
The behavior of PyString was modified quite a bit, to make it more
bytes-like. Some changes are still on the to-do list.
svn+ssh://pythondev@svn.python.org/python/branches/p3yk
........
r56127 | georg.brandl | 2007-06-30 09:32:49 +0200 (Sat, 30 Jun 2007) | 2 lines
Fix a place where floor division would be in order.
........
r56135 | guido.van.rossum | 2007-07-01 06:13:54 +0200 (Sun, 01 Jul 2007) | 28 lines
Make map() and filter() identical to itertools.imap() and .ifilter(),
respectively.
I fixed two bootstrap issues, due to the dynamic import of itertools:
1. Starting python requires that map() and filter() are not used until
site.py has added build/lib.<arch> to sys.path.
2. Building python requires that setup.py and distutils and everything
they use is free of map() and filter() calls.
Beyond this, I only fixed the tests in test_builtin.py.
Others, please help fixing the remaining tests that are now broken!
The fixes are usually simple:
a. map(None, X) -> list(X)
b. map(F, X) -> list(map(F, X))
c. map(lambda x: F(x), X) -> [F(x) for x in X]
d. filter(F, X) -> list(filter(F, X))
e. filter(lambda x: P(x), X) -> [x for x in X if P(x)]
Someone, please also contribute a fixer for 2to3 to do this.
It can leave map()/filter() calls alone that are already
inside a list() or sorted() call or for-loop.
Only in rare cases have I seen code that depends on map() of lists
of different lengths going to the end of the longest, or on filter()
of a string or tuple returning an object of the same type; these
will need more thought to fix.
........
r56136 | guido.van.rossum | 2007-07-01 06:22:01 +0200 (Sun, 01 Jul 2007) | 3 lines
Make it so that test_decimal fails instead of hangs, to help automated
test runners.
........
r56139 | georg.brandl | 2007-07-01 18:20:58 +0200 (Sun, 01 Jul 2007) | 2 lines
Fix a few test cases after the map->imap change.
........
r56142 | neal.norwitz | 2007-07-02 06:38:12 +0200 (Mon, 02 Jul 2007) | 1 line
Get a bunch more tests passing after converting map/filter to return iterators.
........
r56147 | guido.van.rossum | 2007-07-02 15:32:02 +0200 (Mon, 02 Jul 2007) | 4 lines
Fix the remaining failing unit tests (at least on OSX).
Also tweaked urllib2 so it doesn't raise socket.gaierror when
all network interfaces are turned off.
........
number of tests, all because of the codecs/_multibytecodecs issue described
here (it's not a Py3K issue, just something Py3K discovers):
http://mail.python.org/pipermail/python-dev/2006-April/064051.html
Hye-Shik Chang promised to look for a fix, so no need to fix it here. The
tests that are expected to break are:
test_codecencodings_cn
test_codecencodings_hk
test_codecencodings_jp
test_codecencodings_kr
test_codecencodings_tw
test_codecs
test_multibytecodec
This merge fixes an actual test failure (test_weakref) in this branch,
though, so I believe merging is the right thing to do anyway.
(branch-creation time) up to 43067. 43068 and 43069 contain a little
swapping action between re.py and sre.py, and this mightily confuses svn
merge, so later changes are going in separately.
This merge should break no additional tests.
The last-merged revision is going in a 'last_merge' property on '.' (the
branch directory.) Arbitrarily chosen, really; if there's a BCP for this, I
couldn't find it, but we can easily change it afterwards ;)