Antoine Pitrou wrote:
> FWIW, being French, I don't remember hearing any programmer wish (s)he
> could use non-ASCII identifiers, in any programming language. But
> arguably translitteration is very straight-forward (although a bit
> lossless at times ;-)).
My canonical example is François Pinard,
> FWIW, being French, I don't remember hearing any programmer wish (s)he
> could use non-ASCII identifiers, in any programming language. But
> arguably translitteration is very straight-forward (although a bit
> lossless at times ;-)).
>
> I think typeability and reproduceability should be weighte
> Thanks for these data. This mostly reflects my experience with German
> and French users: some people would like to use non-ASCII identifiers
> if they could, other argue they never would as a matter of principle.
> Of course, transliteration is more straight-forward.
FWIW, being French, I don'
On Sat, 2005-10-29 at 10:56 +0200, "Martin v. Löwis" wrote:
> Atsuo Ishimoto wrote:
> > I'm +0.1 for non-ASCII identifiers, although module names should remain
> > ASCII. ASCII identifiers might be encouraged, but as Martin said, it is
> > very useful for some groups of users.
>
> Thanks for these
Atsuo Ishimoto wrote:
> I'm +0.1 for non-ASCII identifiers, although module names should remain
> ASCII. ASCII identifiers might be encouraged, but as Martin said, it is
> very useful for some groups of users.
Thanks for these data. This mostly reflects my experience with German
and French users:
Hello from Japan,
I googled discussions about non-ASCII identifiers in Japanese, but I
found no consensus. Major languages such as Java or VB support non-ASCII
identifiers, so projects uses non-ASCII identifiers for their programs
are existing. Not all Japanese programmers think this is a good ide
Neil Hodgson wrote:
>This is anecdotal but it appears to me that transliterations are
> not commonly used apart from learning languages and some minimal help
> for foreigners such as including transliterated names on railway
> station name boards.
That would be my guess also. Transliteration i
On 10/28/05, Neil Hodgson <[EMAIL PROTECTED]> wrote:
>I used to work on software written by Japanese and English speakers
> at Fujitsu with most developers being Japanese. The rules were that
> comments could be in Japanese but identifiers were only allowed to
> contain ASCII characters. Most v
> "Neil" == Neil Hodgson <[EMAIL PROTECTED]> writes:
Neil> Most variable names were poorly chosen with s, p, q, fla
Neil> (boolean=flag) and flafla being popular. When I asked some
Neil> Japanese coders why they didn't use Japanese words expressed
Neil> in ASCII (Romaji), their
Josiah Carlson:
> According to wikipedia (http://en.wikipedia.org/wiki/Latin_alphabet),
> various languages have adopted a transliteration of their language
> and/or former alphabets into latin. They don't purport to know all of
> the reasons why, and I'm not going to speculate.
I used to wor
Greg Ewing wrote:
> I still think this is a much worse potential problem
> than that of "l" vs "1", etc. It's reasonable to
> adopt the practice of never using "l" as a single
> letter identifier, for example. But it would be
> unreasonable to ban the use of "E" as an identifier
> on the grounds th
Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>
>>If you are told to debug a program
>>written by say a Japanese programmer using Japanese identifiers
>>you are going to have a really hard time.
>
>
> Or you could look upon it as an opportunity to
> broaden your mental horizons by learning some
>
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>You even argued against having non-ASCII identifiers:
>>
>>http://mail.python.org/pipermail/python-list/2002-May/102936.html
>
>
> I see :-) It seems I have changed my mind since then (which
> apparently predates PEP 263).
>
> One issue I appare
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > According to wikipedia (http://en.wikipedia.org/wiki/Latin_alphabet),
> > various languages have adopted a transliteration of their language
> > and/or former alphabets into latin. They don't purport to know all of
> > the r
Martin v. Löwis wrote:
> Not in the literal sense: you certainly want to allow
> "latin" digits in, say, a cyrillic identifier.
Yes, by "alphabet" I really only meant the letters,
although you might want to apply the same idea to
clusters of digits within an identifier, depending
on how potential
M.-A. Lemburg wrote:
> If you are told to debug a program
> written by say a Japanese programmer using Japanese identifiers
> you are going to have a really hard time.
Or you could look upon it as an opportunity to
broaden your mental horizons by learning some
Japanese. :-)
--
Greg Ewing, Compu
Josiah Carlson wrote:
> According to wikipedia (http://en.wikipedia.org/wiki/Latin_alphabet),
> various languages have adopted a transliteration of their language
> and/or former alphabets into latin. They don't purport to know all of
> the reasons why, and I'm not going to speculate.
>
> Whether
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > In this case it's not just a misreading, the characters look identical!
> > When is an 'E' not an 'E'? When it is an Epsilon or Ie. Saying what
> > characters will or will not be used as identifiers, when those
> > char
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> M.-A. Lemburg wrote:
> > You even argued against having non-ASCII identifiers:
> >
> > http://mail.python.org/pipermail/python-list/2002-May/102936.html
> >
> > Do you really think that it will help with code readability
> > if programmers are al
M.-A. Lemburg wrote:
> You even argued against having non-ASCII identifiers:
>
> http://mail.python.org/pipermail/python-list/2002-May/102936.html
I see :-) It seems I have changed my mind since then (which
apparently predates PEP 263).
One issue I apparently was worried about was the plan to us
Greg Ewing asked:
> Would it help if an identifier were required to be
> made up of letters from the same alphabet, e.g. all
> Latin or all Greek or all Cyrillic, but not a mixture.
Probably, yes, though there could still be problems
mixing within a program.
FWIW, the Opera web browser is alread
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>A few years ago we had a discussion about this on python-dev
>>and agreed to stick with ASCII identifiers for Python. I still
>>think that's the right way to go.
>
> I don't think there ever was such an agreement.
You even argued against having n
Am 25.10.2005 um 23:40 schrieb Josiah Carlson:
> [...]
> Identically drawn glyphs are a problem, and pretending that they
> aren't
> a problem, doesn't make it so. Right now, all possible name glyphs
> are
> visually distinct, which would not be the case if any unicode
> character
> could b
> "Josiah" == Josiah Carlson <[EMAIL PROTECTED]> writes:
Josiah> Indeed, they are similar, but_ different_ in my font as
Josiah> well. The trick is that the glyphs are not different in
Josiah> the case of certain greek or cyrillic letters. They don't
Josiah> just /look/ simil
Greg Ewing wrote:
> Would it help if an identifier were required to be
> made up of letters from the same alphabet, e.g. all
> Latin or all Greek or all Cyrillic, but not a mixture.
> Then you'd get an immediate error if you accidentally
> slipped in a letter from the wrong alphabet.
Not in the li
Josiah Carlson wrote:
> In this case it's not just a misreading, the characters look identical!
> When is an 'E' not an 'E'? When it is an Epsilon or Ie. Saying what
> characters will or will not be used as identifiers, when those
> characters are keys on a keyboard of a specific type, is pretty
Martin v. Löwis wrote:
> For window.draw, people will readily understand that
> they are supposed to use Latin letters. More generally, they will know
> what script to use just from looking at the identifier.
Would it help if an identifier were required to be
made up of letters from the same alph
Martin v. Löwis:
> This aspect of rendering is often not implemented, though. Web browsers
> do it correctly, see
> ...
> GUI frameworks sometimes do it correctly, sometimes don't; most
> notably, Tk has no good support for RTL text.
Scintilla does a rough job with this. RTL text is displayed
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 10/25/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Indeed, they are similar, but_ different_ in my font as well. The trick
> > is that the glyphs are not different in the case of certain greek or
> > cyrillic letters. They don't just /look
On 10/25/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Indeed, they are similar, but_ different_ in my font as well. The trick
> is that the glyphs are not different in the case of certain greek or
> cyrillic letters. They don't just /look/ similar they /are identical/.
Well, in the font I'm u
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > And how users could say, "name error? But I typed in window.draw(PEN) as
> > I was told to, and it didn't work!"
>
> Ah, so the "serious issues" you are talking about are not security
> issues, but usability issues.
Ind
Guido van Rossum wrote:
> This actually seems a killer even for allowing Unicode in comments,
> which I'd otherwise favor. What do Unicode-aware apps generally do
> with right-to-left characters?
The Unicode standard has an elaborate definition of what should happen.
There are many rules to it, bu
M.-A. Lemburg wrote:
> A few years ago we had a discussion about this on python-dev
> and agreed to stick with ASCII identifiers for Python. I still
> think that's the right way to go.
I don't think there ever was such an agreement.
Regards,
Martin
___
Josiah Carlson wrote:
> And how users could say, "name error? But I typed in window.draw(PEN) as
> I was told to, and it didn't work!"
Ah, so the "serious issues" you are talking about are not security
issues, but usability issues.
I don't think extending the range of acceptable characters will
On 10/25/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Identically drawn glyphs are a problem, and pretending that they aren't
> a problem, doesn't make it so. Right now, all possible name glyphs are
> visually distinct, which would not be the case if any unicode character
> could be used as a n
Josiah Carlson wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>>Fredrik Lundh wrote:
>>
>>>however, for Python 3000, it would be nice if the source-code encoding
>>>applied
>>>to the *entire* file (XML-style), rather than just unicode string literals
>>>and (hope-
>>>fully) comments and
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > It seems that removing this restriction may cause serious issues, at
> > least in the case when using cyrillic characters in names. See recent
> > security issues in regards to web addresses in web browsers for the
> > co
Josiah Carlson wrote:
> It seems that removing this restriction may cause serious issues, at
> least in the case when using cyrillic characters in names. See recent
> security issues in regards to web addresses in web browsers for the
> confusion (and/or name errors) that could result in their use
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
> > however, for Python 3000, it would be nice if the source-code encoding
> > applied
> > to the *entire* file (XML-style), rather than just unicode string literals
> > and (hope-
> > fully) comments and docstrings.
>
> As
Fredrik Lundh wrote:
> however, for Python 3000, it would be nice if the source-code encoding applied
> to the *entire* file (XML-style), rather than just unicode string literals
> and (hope-
> fully) comments and docstrings.
As MAL explains, the encoding currently does apply to the entire file.
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>
>>I don't follow you here. The source code encoding
>>is only applied to Unicode literals (you are using string
>>literals in your example). String literals are passed
>>through as-is.
>
>
> however, for Python 3000, it would be nice if the source
M.-A. Lemburg wrote:
> I don't follow you here. The source code encoding
> is only applied to Unicode literals (you are using string
> literals in your example). String literals are passed
> through as-is.
however, for Python 3000, it would be nice if the source-code encoding applied
to the *enti
42 matches
Mail list logo
