> string.zfill has a "decadent feature": It also works for
> non-string objects by calling repr before formatting.
Hm, but repr() was the wrong thing to call here anyway. :-(
> > c in string.whitespace --> c.isspace()
>
> This changes the meaning slightly for unicode characters, because
> chr(i).isspace() != unichr(i).isspace()
> for i in { 0x1c, 0x1d, 0x1e, 0x1f, 0x85, 0xa0 }
That's unfortunate, because I'd like unicode to be an extension of
ASCII also in this kind of functionality. What are these and why are
they considered spaces? Would it hurt to make them spaces in ASCII
too?
> New ones:
>
> Pattern: "foobar"[:3] == "foo" -> "foobar".startswith("foo")
> "foobar"[-3:] == "bar" -> "foobar".endswith("bar")
> Version: ??? (It was added on the string_methods branch)
2.0.
> Benefits: Faster because no slice has to be created.
> No danger of miscounting.
> Locating: grep "\[\w*-[0-9]*\w*:\w*\]" | grep "=="
> grep "\[\w*:\w*[0-9]*\w*\]" | grep "=="
Are these regexes really worth making part of the migration guide?
\w* isn't a good pattern to catch an arbitrary expression, it only
catches simple identifiers!
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4