>
> Agreed. One of the handy traits of cross-platform code is that MANY
> languages let you subscript a double-quoted string to get a
> single-quoted character. Compare these blocks of code:
>
> if ("asdf"[0] == 'a')
> write("The first letter of asdf is a.\n");
>
> if ("asdf"[0] == 'a'):
> print("The first letter of asdf is a.")
>
> if ("asdf"[0] == 'a')
> console.log("The first letter of asdf is a.")
>
> if ("asdf"[0] == 'a')
> printf("The first letter of asdf is a.\n");
>
> if ("asdf"[0] == 'a')
> echo("The first letter of asdf is a.\n");
>
> Those are Pike, Python, JavaScript/ECMAScript, C/C++, and PHP,
> respectively. Two of them treat single-quoted and double-quoted
> strings identically (Python and JS). Two use double quotes for strings
> and single quotes for character (aka integer) constants (Pike and C).
> One has double quotes for interpolated and single quotes for
> non-interpolated strings (PHP). And just to mess you up completely,
> two (or three) of these define strings to be sequences of bytes (C/C++
> and PHP, plus Python 2), two as sequences of Unicode codepoints
> (Python and Pike), and one as sequences of UTF-16 code units (JS). But
> in all five, subscripting a double-quoted string yields a
> single-quoted character.
>
> I'm firmly of the opinion that this should not change. Code clarity is
> not helped by creating a brand-new "character" type and not having a
> corresponding literal for it, and the one obvious literal, given the
> amount of prior art using it, would be some form of quote character -
> probably the apostrophe. Since that's not available, I think a
> character type would be a major hurdle to get over.
I was not proposing a character type, only that strings are not iterable:
for i in 'abc':
print(i)
TypeError: 'str' object is not iterable
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
