> Those examples would be a lot more compelling if there was an
> acceptable way to input those characters. Maybe we could support some
> kind of input method that enabled LaTeX style math notation as used by
> scientists for writing equations in papers?
Antoine Pitrou wrote: > Oh but why isn't it named Python für Kinder? :-)
It looks like Germans have adopted "kid" as an abbreviation for "kinder", just like we use it as an abbreviation for "child". Or maybe we got it from them -- it's closer to their original word than ours!
They seem to be using our plural, though -- "kids", not "kidden"...
>> Oh but why isn't it named Python für Kinder? :-)
> It looks like Germans have adopted "kid" as an abbreviation > for "kinder", just like we use it as an abbreviation for > "child". Or maybe we got it from them -- it's closer to > their original word than ours!
> They seem to be using our plural, though -- "kids", not > "kidden"...
Sometimes we use the ...s for plural as well, especially for acronyms, words of English or French origin and last names. But it would not be ...en, maybe ...er. Is there any German word that uses ...en for plural? I don't think so. Anyway, "kids" is definitely an anglicism, because we pronounce it "English" and not like it would be pronounced if it where derived from "Kind" (it would be more like "keed"). German today is full of anglicisms.
But then, there are some German words used by English people as well: gesundheit, kindergarten, über, blitz(krieg), angst (used as something different as the German word), abseiling ("abseilen" in German), doppelgänger, gestalt, poltergeist, Zeitgeist... _______________________________________________ Python-ideas mailing list Python-id...@python.org http://mail.python.org/mailman/listinfo/python-ideas
> it does make sense. The only point I tried to make is that,
> because something is allowed, it does mean it should be
> encouraged. I am sure there are instructors who want to teach
>to code using Japanese of Chinese variable names. Python gives
> them a way to do so. Yet, if they do so, they would be
>isolating their students and their code from the rest of the
>world.
People very often over-estimate the cost of that isolation, and
over-value access to the rest of the world.
The average open source piece of software has one, maybe two,
contributors. What do they care if millions of English-speaking
programmers can't contribute when they weren't going to contribute
regardless of the language? Perhaps the convenience of being able
to read your own code in your own native language outweighs the
loss of being able to attract contributors that you can't even
talk to.
And for proprietary software, again it is irrelevant. If a Chinese
company writes Chinese software for Chinese users with Chinese
developers, why would they want to write it in English? Perhaps
they have little choice due to the overwhelming trend towards English
in programming languages, but there's no positive benefit to using
a non-native language.
Quite frankly, and I'm saying this as somebody who only speaks
English, I think that the use of English as the single lingua franca
of computer programming is as unnecessary (and ultimately as harmful)
as the use of Latin and then French as the sole lingua franca of
science and mathematics. I expect that it too will be a passing phase.
By the way, are you familiar with ChinesePython and IronPerunis?
> I still don't understand why unicode characters are allowed at all > in identifier names.
"Consenting adults." 'nuff said?
An anecdote. Back when I was first learning Japanese, I maintained an Emacs interface to EDICT, a free Japanese-English dictionary. The code was smart enough to parse morphosyntax (inflection of verbs and adjectives) into dictionary forms, but I wasn't (and according to my daughter, still am not<wink/>). So I asked my tutor for help.
Although a total non-programmer, he was able to read the grammar easily because the state names (identifiers for callable objects) were written in Japanese, using the standard grammatical name for the inflection. The "easy" part comes in because although his English was good, it wasn't good enough to disentangle Lisp gobbledygook from the morphosyntax data had it been written in ASCII. But he was able to read and comment on the whole grammar in about half an hour because he could just skip *all* the ASCII!
> Those examples would be a lot more compelling if there was an
> acceptable way to input those characters.
Hey!! What's "unacceptable" about Emacs??<duck/>
> Maybe we could support some kind of input method that enabled LaTeX
> style math notation as used by scientists for writing equations in
> papers?
If you're talking about interactive use, Emacs has a method based on
searching the Unicode character database.
LaTeX math notation has a number of potential pitfalls. In
particular, the sub-/superscript notation can be applied to anything,
not just characters that happen to have *script versions in Unicode.
Also, not everything that seems to a character in LaTeX necessarily
has a corresponding Unicode character.
_______________________________________________
Python-ideas mailing list
Python-id...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
Matthew Woodcraft <matt...@woodcraft.me.uk> writes:
> On 2012-10-01 21:51, Guido van Rossum wrote: > > Those examples would be a lot more compelling if there was an > > acceptable way to input those characters. Maybe we could support > > some kind of input method that enabled LaTeX style math notation as > > used by scientists for writing equations in papers?
> I think that's up to the OS or the text editor.
Agreed. Make of these identifiers will need to be typed at an OS command line, after all (e.g. for naming a test case to run, as one which springs easily to mind).
Solve the keyboard input problem in the OS layer – as someone who anticipates working with non-ASCII characters must already do – and you solve it for Python code as well. I don't think it's Python's business to get involved at the input method level.
-- \ “The apparent lesson of the Inquisition is that insistence on | `\ uniformity of belief is fatal to intellectual, moral, and | _o__) spiritual health.” —_The Uses Of The Past_, Herbert J. Muller | Ben Finney
> Solve the keyboard input problem in the OS layer – as someone who > anticipates working with non-ASCII characters must already do – and you > solve it for Python code as well.
That simply isn't true for symbol characters and Greek letters. I still let either TeX or XEmacs translate TeX macros for me. I don't even know how to type an integral sign in Mac OS X Terminal (conveniently, that is -- of course there's always the character palette), and if I wanted directed quotation marks (I don't), I'd just use ASCII quotes and let XEmacs translate those, too.
There ought to be a standard way to get those symbols and punctuation, preferably ASCII-based, on any terminal, using the standard Python interpreter.
> Those examples would be a lot more compelling if there was an
> acceptable way to input those characters. Maybe we could support some
> kind of input method that enabled LaTeX style math notation as used by
> scientists for writing equations in papers?
\u03B1
Java already allows this outside of the string literals. And it sometimes causes unpleasant effects.
"Stephen J. Turnbull" <step...@xemacs.org> writes:
> I still let either TeX or XEmacs translate TeX macros for me. I don't > even know how to type an integral sign in Mac OS X Terminal > (conveniently, that is -- of course there's always the character > palette), and if I wanted directed quotation marks (I don't), I'd just > use ASCII quotes and let XEmacs translate those, too.
Right. So you've solved it for one program only, not the OS which is (or should be) responsible for turning what you type into characters, uniformly across all applications you have keyboard input for.
> There ought to be a standard way to get those symbols and punctuation, > preferably ASCII-based, on any terminal
Definitely agreed with this. Indeed, it's my point: the problem should be solved in one place for the user of the computer, not separately per application or framework.
> using the standard Python interpreter.
If you mean that the Python interpreter should be aware of the solution, why? That's solving it at the wrong level, because any non-Python program (such as a shell or an editor) gets no benefit from that.
If you mean that the single, one-point solution should work across all programs, including the standard Python interpreter, then yes I agree.
I'm saying the OS is the right place to solve it, by installing an appropriate input method (or whatever each OS calls them).
-- \ “In economics, hope and faith coexist with great scientific | `\ pretension and also a deep desire for respectability.” —John | _o__) Kenneth Galbraith, 1970-06-07 | Ben Finney
> > > I still let either TeX or XEmacs translate TeX macros for me. I don't
> > even know how to type an integral sign in Mac OS X Terminal
> > (conveniently, that is -- of course there's always the character
> > palette), and if I wanted directed quotation marks (I don't), I'd just
> > use ASCII quotes and let XEmacs translate those, too.
> > Right. So you've solved it for one program only, not the OS
You seem to be under a misconception. Emacs *is* an OS, it just runs
on top of the more primitive OSes normally associated with the term. ;-)
> I'm saying the OS is the right place to solve it, by installing an
> appropriate input method (or whatever each OS calls them).
I doubt very many people used to and fond of LaTeX would agree with
you, since AFAIK there aren't any OSes providing TeX macros as an
input method. AFAICS it's not available on my Mac.
While I don't particularly favor it, it may be the best compromise, as
many people are familiar with it, and many many symbols are available
with familiar, intuitive names so that non-TeXnical typists can often
guess them.
_______________________________________________
Python-ideas mailing list
Python-id...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
"Stephen J. Turnbull" <step...@xemacs.org> writes:
> Ben Finney writes: > > Right. So you've solved it for one program only, not the OS
> You seem to be under a misconception. Emacs *is* an OS […]
… all it needs is a good editor? :-)
(I'm claiming permission for that snark because Emacs is my primary editor.)
> > I'm saying the OS is the right place to solve it, by installing an > > appropriate input method (or whatever each OS calls them).
> I doubt very many people used to and fond of LaTeX would agree with > you, since AFAIK there aren't any OSes providing TeX macros as an > input method.
I've shown several LaTeX-comfortable people IBus on GNOME and/or KDE (for GNU+Linux), and they were very glad that it has a LaTeX input method. So anyone who is fond of LaTeX and has IBus or an equivalent input method engine on their OS can agree.
> AFAICS it's not available on my Mac.
That's a shame. Maybe some OS vendors don't want to support users extending the OS functionality? Or maybe your OS does have such a thing available. I haven't been motivated to look for it.
> While I don't particularly favor it, it may be the best compromise, as > many people are familiar with it, and many many symbols are available > with familiar, intuitive names so that non-TeXnical typists can often > guess them.
Agreed. Which is why I advocate installing such an input method in one's OS input method engine, so that input method is available for all applications.
-- \ “I thought I'd begin by reading a poem by Shakespeare, but then | `\ I thought ‘Why should I? He never reads any of mine.’” —Spike | _o__) Milligan | Ben Finney
> I've shown several LaTeX-comfortable people IBus on GNOME and/or KDE
> (for GNU+Linux), and they were very glad that it has a LaTeX input
> method.
I'm happy to be proved wrong!
> > AFAICS it's not available on my Mac.
> > That's a shame. Maybe some OS vendors don't want to support users
> extending the OS functionality? Or maybe your OS does have such a thing
> available. I haven't been motivated to look for it.
I have looked for it; if it's available on Mac OS X, it's not easy to
find. I suspect the same is true for Windows.
> Agreed. Which is why I advocate installing such an input method in one's
> OS input method engine, so that input method is available for all
> applications.
Whatever makes you think I don't? That's *exactly* why I live in
XEmacs, because it provides me with a portable environment for mixing
English and math with a language whose orthography puts Brainf*ck
syntax to shame.
But pragmatically speaking, Unicode support is a sore point for
Python. "Screw you if you don't know how to conveniently input
integral signs on your OS" is not a message we want to be sending.
_______________________________________________
Python-ideas mailing list
Python-id...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
