[Python-3000] PEP 3131 accepted

[Josiah Carlson]

"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> Josiah Carlson writes:
>  > Removing those words that some found offensive, perhaps I will get a
>  > reponse to the point of my post: "your tools aren't very good" and
>  > "Emacs does it right" are not valid responses to the concerns brought up
>  > regarding unicode.
> 
> You're missing my point still, and I don't find the words offensive.
> (It's a pain in the neck, since I already wrote my reply, but I'll
> remove them too.)  Nor do I find your completely groundless conclusion
> that I'm deprecating other tools offensive.

I'll skip to the chase here.

Much of my concerns could be addressed through the use of commandline,
environment variable, or in-source code definitions of what are
allowable identifier characters.  Generally, in-source definitions (like
the coding: directive) are the most flexible, but are the biggest pain
for editors and IDEs (which may want to verify every identifier as it is
being typed, etc.).  The not insignificant problem is that it allows for
identifier characters to be defined on a per-module basis.  This is
'fixed' by commandline/environment variables, but it also makes running
(rather than editing) a bigger pain than it should be.


If people can agree on a method for specifying, 'ascii only', 'ascii +
character sets X, Y, Z', and it actually becomes an accepted part of the
proposal, gets implemented, etc., I will grumble to myself at home, but
I will stop trying to raise a stink here.


> I find them to be an indicator of your fears which cannot be grounded
> in any experience of mine---in exactly the kind of environment PEP
> 3131 will provide.  I strongly suspect you have no experience at all,
> not even hearsay, to offer.  *Please* prove me wrong!  My experience
> is *far* from definitive.

My "fear" is that being able to prove (to myself and others) that the
code I am looking at does what it should do.  As you say, maybe I will
never see non-ascii source in my life.  But even if I don't, I know some
of my users will, and to not be American-centric, I need to continue to
provide them with "tools that don't suck" (which will likely necessitate
testing using non-ascii identifiers).


> But addressing the content of what you write, you mean that, in a
> world that allows multilingual identifiers, 'Emacs works' "smells
> like" [from your original post] a threat to the market share of
> editors that can't deal with multilingual identifiers, not to mention
> the work habits of Emacs-haters everywhere, don't you?

Please understand me, I don't hate Emacs.  I also don't hate Vim.  I
just don't find that they fit my personal aesthetics for doing what I
like and need to do: write Python (and a few others).  And because I'm
not selling my editor, I don't really care about (my) market share. What
I care about is functional tools for everyone who wants to use Python.

To me, that means that people should be able to write software in
whatever tool they currently prefer, whether that is Emacs, Vim, Eric3,
Idle, SPE, NewEdit, DrPython, PythonWin, Scite, PyPE, Nedit, Kate, Gedit,
Leo, Boa Constructor, Windows Notepad, Visual Studio, etc.  Some of
those will get certain functionality for free (due to their use of the
same editing component), but each will need to write their own "discover
usable characters, verify identifiers, report to user" mechanism (though
some will opt for merely syntax highlighting).  Some will want/need
alternate input methods for needing to write characters out of a user's
locale.

Who knows, maybe it is as simple as a 5 line change.  And maybe it won't
be as big a problem as we are concerned about.  But "it's not a problem",
"in my experience with Java", and "Emacs users rarely if ever have to
deal with such things" don't make me feel any better about the issues
regarding Python and editors that aren't Emacs*.


 - Josiah

* Partly because I don't know the market share that Emacs has with Java
developers, and/or whether Java editor market share is flat across
national boundaries.