> > Please note that
> > u'<whatever-in-ascii>' is interpreted just literally and we
> > cannot put Japanese characters in string literals legally for
> > now anyway.
>
> Would you like to be able to? The PEP will allow this -- that's its
> whole point!
Yes, I would. And I wish that the PEP would
(1) allow once-and-for-all transition to the new scheme
(if the default encoding will be UTF-8 in the far future and
encoding spedifications will lose their significance someday,
I'd rather like to use UTF-8 as the default for now), and
(2) not break any legal code, unless the breaking is reasonably
tolerable one.
> > It sounds very nice. I understand that the default data
> > encoding will be applied to what from file objects. It must be
> > the only(?) satisfying solution if the default source encoding
> > is to be set in site.py.
> > # Or else we should give up the default encoding for data...
>
> I would strongly encourage the latter. Are you really sure that there
> isn't a better way to avoid having to type the encoding name all the
> time? E.g. define your own helper functions?
Certainly there would be. Anyway in that Martin v. Loewis
advised me on the danger of using UTF-16 as the default encoding
in the _current_ Python, we will do up things.
# Though currently we do not meet severe problems luckily. If
# there is danger, I wonder it might be a bug of the current
# Python.
> > I'm sorry for the ambiguity.
> > I proposed ASCII as the _minimum_ request. I'd _hope_ UTF-8.
> I will ignore the rest of your message, which is just repeating
> age-old arguments why we should use UTF-8. We have considered this
> carefully in the past, and rejected the idea. I see nothing new in
> your argument.
> And yes, using ASCII is unfair to all non-English speakers. But
> Python uses English keywords anyway; I don't think we should strive
> for total cultural relativism, and it's certainly not a fight I feel
> the desire to fight for now.
I see, though it is regrettable.
Personally speaking, _I_ have been using the same source files
written in UTF-8 among the various environments at home as a
hobby: BeOS, MacOS X, GNU/Linux and Windows Me/XP. They run
very well for now without any encoding conversion.
# In fact the "pypage" Web server referred in my reply to Martin
# v. Loewis is such one. It runs very well on the current
# Python almost everywhere because it does not treat strings as
# Unicode at all for now.
Strictly speaking, they are illegal and I have no right to
insist for them at all. Yes, I will put either the magic
comment or UTF-8 BOM on all of them.
# In fact I will use the magic comment because I want to make my
# program runnable in many versions of Python as possible.
--
SUZUKI Hisao <suzuki@acm.org> <suzuki611@okisoft.co.jp>
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