By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,490 Members | 1,398 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,490 IT Pros & Developers. It's quick & easy.

Using non-ascii symbols

P: n/a
On the page http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).

This should be an evolution similar to the digraphe and trigraph
(digramme et trigramme) from C and C++ languages."

How do people on this group feel about this suggestion?

The symbols above are not even latin-1, you need utf-8.

(There are not many usefuls symbols in latin-1. Maybe one could use ×
for cartesian products...)

And while they are better readable, they are not better typable (at
least with most current editors).

Is this idea absurd or will one day our children think that restricting
to 7-bit ascii was absurd?

Are there similar attempts in other languages? I can only think of APL,
but that was a long time ago.

Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?
Opinions?

-- Christoph
Jan 24 '06 #1
Share this Question
Share on Google+
61 Replies


P: n/a
Christoph Zwerschke wrote:
On the page http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).

This should be an evolution similar to the digraphe and trigraph
(digramme et trigramme) from C and C++ languages."

How do people on this group feel about this suggestion?

The symbols above are not even latin-1, you need utf-8.

(There are not many usefuls symbols in latin-1. Maybe one could use ×
for cartesian products...)

And while they are better readable, they are not better typable (at
least with most current editors).

Is this idea absurd or will one day our children think that restricting
to 7-bit ascii was absurd?

Are there similar attempts in other languages? I can only think of APL,
but that was a long time ago.

Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?
Opinions?

-- Christoph


I can't find "≤, ≥, or *" on my keyboard.

James
Jan 24 '06 #2

P: n/a
James Stroud wrote:
I can't find "≤, ≥, or *" on my keyboard.


Get a better keyboard? or OS?

On OS X,

≤ is Alt-,
≥ is Alt-.
* is Alt-=

Fewer keystrokes than <= or >= or !=.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Jan 24 '06 #3

P: n/a
Robert Kern wrote:
I can't find "?, ?, or ?" on my keyboard.


Get a better keyboard? or OS?

On OS X,

? is Alt-,
? is Alt-.
? is Alt-=

Fewer keystrokes than <= or >= or !=.


Sure, but I can't find OS X listed as a prerequisite for using Python. So,
while I don't give a damn if those symbols are going to be supported by Python,
I don't think the plain ASCII version should be deprecated. There are too many
situations where it's still useful (coding across old terminals and whatnot).
--
Giovanni Bajo
Jan 24 '06 #4

P: n/a
On Tue, 24 Jan 2006 04:09:00 +0100, Christoph Zwerschke wrote:
On the page http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).

This should be an evolution similar to the digraphe and trigraph
(digramme et trigramme) from C and C++ languages."

How do people on this group feel about this suggestion?

The symbols above are not even latin-1, you need utf-8.

(There are not many usefuls symbols in latin-1. Maybe one could use ×
for cartesian products...)
Or for multiplication :-)

And while they are better readable, they are not better typable (at
least with most current editors).

Is this idea absurd or will one day our children think that restricting
to 7-bit ascii was absurd?

Are there similar attempts in other languages? I can only think of APL,
but that was a long time ago.
My earliest programming was on (classic) Macintosh, which supported a
number of special characters including ≤ ≥ * with the obvious
meanings. They were easy to enter too: the Mac keyboard had (has?) an
option key, and holding the option key down while typing a character would
enter a special character. E.g. option-s gave Greek sigma, option-p gave
pi, option-less-than gave ≤, and so forth. Much easier than trying to
memorize character codes.

I greatly miss the Mac's ease of entering special characters, and I miss
the ability to use proper mathematical symbols for (e.g.) pi, not equal,
and so forth.
Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?
Opinions?


I think the use of digraphs like != for not equal is a poor substitute for
a real not-equal symbol. I think the reliance of 7-bit ASCII is horrible
and primitive, but without easier, more intuitive ways of entering
non-ASCII characters, and better support for displaying non-ASCII
characters in the console, I can't see this suggestion going anywhere.

--
Steven.

Jan 24 '06 #5

P: n/a
Christoph Zwerschke wrote:
On the page http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).

This should be an evolution similar to the digraphe and trigraph
(digramme et trigramme) from C and C++ languages."

How do people on this group feel about this suggestion?

The symbols above are not even latin-1, you need utf-8.

(There are not many usefuls symbols in latin-1. Maybe one could use ×
for cartesian products...)

And while they are better readable, they are not better typable (at
least with most current editors).

Is this idea absurd or will one day our children think that restricting
to 7-bit ascii was absurd?

Are there similar attempts in other languages? I can only think of APL,
but that was a long time ago.

Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?
Opinions?

-- Christoph


One of issues in Python is cross-platform portability. Limiting the
range of symbols to lower ASCII and with specification of a code table
to ASCII is a good deal here. I think, that Unicode is not yet
everywhere and as long it is that way it makes not much sense to go for
it in Python.

Claudio
Jan 24 '06 #6

P: n/a
>> Is this idea absurd or will one day our children think
that restricting to 7-bit ascii was absurd?


Both... this idea will only become none-absurd when unicode will become
as prevalent as ascii, i.e. unicode keyboards, universal support under
almost every application, and so on. Even if you can easly type it on
your macintosh, good luck using it while using said macintosh to ssh or
telnet to a remote server and trying to type unicode...

Jan 24 '06 #7

P: n/a
Christoph Zwerschke wrote:
"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).


I assume most python beginners know some other programming language, and
are familiar with the >= and friends. Those learning python as their
first programming language will benefit from learning the >= when they
learn a new language.

Unicode is not yet supported everywhere, so some editors/terminals might
display the suggested one-char operators as something else, effectively
"guess what operator I was thinking".

Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90
uses ! as comment symbol and therefore need /= instead of != for
inequality. I guess just because they wanted. However, it is one more
needless detail to remember. Same with the suggested operators.
Jan 24 '06 #8

P: n/a
Giovanni Bajo wrote:
Robert Kern wrote:

I can't find "?, ?, or ?" on my keyboard.


Posting code to newsgroups might get harder too. :-)
Jan 24 '06 #9

P: n/a
Rocco Moretti wrote:

[James Stroud wrote:]
I can't find "?, ?, or ?" on my keyboard.


Posting code to newsgroups might get harder too. :-)


His post made it through fine. Your newsreader messed it up.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Jan 24 '06 #10

P: n/a
Giovanni Bajo wrote:
Sure, but I can't find OS X listed as a prerequisite for using Python. So,
while I don't give a damn if those symbols are going to be supported by Python,
I don't think the plain ASCII version should be deprecated. There are too many
situations where it's still useful (coding across old terminals and whatnot).


I think we should limit the discussion to allowing non-ascii symbols
*alternatively* to (combinations of) ascii chars. Nobody should be
forced to use them since not all editors/OSs and keyboards support it.

Think about moving from ASCII to LATIN-1 or UTF-8 as similar to moving
from ISO 646 to ASCII (http://en.wikipedia.org/wiki/C_trigraph).

I think it is a legitimate question, after UTF-8 becomes more and more
supported.

Editors could provide means to easily enter these symbols once
programming languages start supporting them: Automatic expansion of
ascii combinations, Alt-Combinations (like in OS-X) or popup menus with
all supported symbols.

-- Christoph
Jan 24 '06 #11

P: n/a
Christoph Zwerschke wrote:
On the page http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).

This should be an evolution similar to the digraphe and trigraph
(digramme et trigramme) from C and C++ languages."

How do people on this group feel about this suggestion?

The symbols above are not even latin-1, you need utf-8.

(There are not many usefuls symbols in latin-1. Maybe one could use ×
for cartesian products...)

And while they are better readable, they are not better typable (at
least with most current editors).

Is this idea absurd or will one day our children think that restricting
to 7-bit ascii was absurd?

Are there similar attempts in other languages? I can only think of APL,
but that was a long time ago.

Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?
Opinions?

-- Christoph


This will eventually happen in some form. The problem is that we are
still in the infancy of computing. We are using stones and chisels to
express logic. We are currently faced with text characters with which
to express intent. There will come a time when we are able to represent
a program in another form that is readily portable to many platforms.

In the meantime (probably 50 years or so), it would be advantageous to
use a universal character set for coding programs. To that end, the
input to the Python interpreter should be ISO-10646 or a subset such as
Unicode. If the # -*- coding: ? -*- line specifies something other than
ucs-4, then a preprocessor should convert it to ucs-4. When it is
desireable to avoid the overhead of the preprocessor, developers will
find a way to save source code in ucs-4 encoding.

The problem with using Unicode in utf-8 and utf-16 forms is that the
code will forever need to be written and forever execute additional
processing to handle the MBCS and MSCS (Multiple-Short Character Set)
situation.

Ok. Maybe computing is past infancy. But most development environments
are not much past toddler stage.
Jan 24 '06 #12

P: n/a
Ido Yehieli wrote:
Is this idea absurd or will one day our children think
that restricting to 7-bit ascii was absurd?


Both... this idea will only become none-absurd when unicode will become
as prevalent as ascii, i.e. unicode keyboards, universal support under
almost every application, and so on. Even if you can easly type it on
your macintosh, good luck using it while using said macintosh to ssh or
telnet to a remote server and trying to type unicode...


[~]$ ssh rk***@192.168.1.66
rk***@192.168.1.66's password:
Linux rkernx2 2.6.12-9-amd64-generic #1 Mon Oct 10 13:27:39 BST 2005 x86_64
GNU/Linux

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Mon Jan 9 12:40:28 2006 from 192.168.1.141
[~]$ cat > utf-8.txt
x + y ≥ z
[~]$ cat utf-8.txt
x + y ≥ z

Luck isn't involved.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Jan 24 '06 #13

P: n/a
Juho Schultz wrote:
Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90
uses ! as comment symbol and therefore need /= instead of != for
inequality. I guess just because they wanted. However, it is one more
needless detail to remember. Same with the suggested operators.


The point is that it is just *not* the same. The suggested operators are
universal symbols (unicode). Nobody would use * as a comment sign. No
need to remember was it .NE. or -ne or <> or != or /= ...

There is also this old dispute of using "=" for both the assignment
operator and equality and how it can confuse newcomers and cause errors.
A consequent use of unicode could solve this problem:

a ← b # Assignment (now "a = b" in Python, a := b in Pascal)
a = b # Eqality (now "a == b" in Python, a = b in Pascal)
a ≡ b # Identity (now "a is b" in Python, @a = @b in Pascal)
a ≈ b # Approximately equal (may be interesting for floats)

(I know this goes one step further as it is incompatible to the existing
use of the = sign in Python).

Another aspect: Supporting such symbols would also be in accord with
Python's trait of being "executable pseudo code."

-- Christoph
Jan 24 '06 #14

P: n/a
On Tue, 24 Jan 2006 16:33:16 +0200 in comp.lang.python, Juho Schultz
<ju**********@helsinki.fi> wrote:

[...]

Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90
uses ! as comment symbol and therefore need /= instead of != for
inequality. I guess just because they wanted. However, it is one more
needless detail to remember. Same with the suggested operators.


C uses ! as a unary logical "not" operator, so != for "not equal" just
seems to follow, um, logically.

Pascal used <>, which intuitively (to me, anyway ;-) read "less than
or greater than," i.e., "not equal." Perl programmers might see a
spaceship.

Modula-2 used # for "not equal." I guess that wouldn't work well in
Python...

Regards,
-=Dave

--
Change is inevitable, progress is not.
Jan 24 '06 #15

P: n/a
On Tue, 24 Jan 2006 04:09:00 +0100 in comp.lang.python, Christoph
Zwerschke <ci**@online.de> wrote:

[...]
Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?


The latter, IMHO. Especially variable names. Consider i vs. vs.
vs. vs. vs. ...

Regards,
-=Dave

--
Change is inevitable, progress is not.
Jan 24 '06 #16

P: n/a
Robert Kern wrote:
Rocco Moretti wrote:

[James Stroud wrote:]
>I can't find "?, ?, or ?" on my keyboard.


Posting code to newsgroups might get harder too. :-)

His post made it through fine. Your newsreader messed it up.


I'm not exactally sure what happened - I can see the three charachters
just fine in your (Robert's) and the original (Christoph's) post. In
Giovanni's post, they're rendered as question marks.

My point still stands: _somewere_ along the way the rendering got messed
up for _some_ people - something that wouldn't have happened with the
<=, >= and != digraphs.

(FWIW, my newsreader is Thunderbird 1.0.6.)
Jan 24 '06 #17

P: n/a
Christoph Zwerschke wrote:
Juho Schultz wrote:
Fortran 90 allowed >, >= instead of .GT., .GE. of Fortran 77. But F90
uses ! as comment symbol and therefore need /= instead of != for
inequality. I guess just because they wanted. However, it is one more
needless detail to remember. Same with the suggested operators.

The point is that it is just *not* the same. The suggested operators are
universal symbols (unicode). Nobody would use * as a comment sign. No
need to remember was it .NE. or -ne or <> or != or /= ...

There is also this old dispute of using "=" for both the assignment
operator and equality and how it can confuse newcomers and cause errors.
A consequent use of unicode could solve this problem:

Being involved in the discussion about assignment and looking for new
terms which do not cause confusion when explaining what assignment does,
this proposal seems to be a kind of solution:
a ← b # Assignment (now "a = b" in Python, a := b in Pascal) ^-- this seems to me to be still open for further proposals and
discussion. There is no symbol coming to my mind, but I would be glad if
it would express, that 'a' becomes a reference to a Python object being
currently referred by the identifier 'b' (maybe some kind of <-> ?). a = b # Eqality (now "a == b" in Python, a = b in Pascal)
a ≡ b # Identity (now "a is b" in Python, @a = @b in Pascal)
a ≈ b # Approximately equal (may be interesting for floats) ^-- this three seem to me to be obvious and don't need to be
further discussed (only implemented as the time for such things will come).

Claudio
(I know this goes one step further as it is incompatible to the existing
use of the = sign in Python).

Another aspect: Supporting such symbols would also be in accord with
Python's trait of being "executable pseudo code."

-- Christoph

Jan 24 '06 #18

P: n/a
Rocco Moretti schrieb:
My point still stands: _somewere_ along the way the rendering got messed
up for _some_ people - something that wouldn't have happened with the
<=, >= and != digraphs.


Yes, but Python is already a bit handicapped concerning posting code
anyway because of its significant whitespace. Also, I believe once
Python will support this, the editors will allow converting "digraphs"
<=, >= and != to symbols back and forth, just as all editors learned to
convert tabs to spaces back and forth... And newsreaders and mailers are
also improving. Some years ago, I used to write all German Umlauts as
digraphs because you could never be sure how they arrived. Nowadays, I'm
using Umlauts as something very normal.

-- Christoph
Jan 24 '06 #19

P: n/a
Christoph Zwerschke wrote:
My point still stands: _somewere_ along the way the rendering got messed
up for _some_ people - something that wouldn't have happened with the
<=, >= and != digraphs.


Yes, but Python is already a bit handicapped concerning posting code
anyway because of its significant whitespace. Also, I believe once
Python will support this, the editors will allow converting "digraphs"
<=, >= and != to symbols back and forth


umm. if you have an editor that can convert things back and forth, you
don't really need language support for "digraphs"...

</F>

Jan 24 '06 #20

P: n/a
UTF-8 is also the standard encoding of SuSE Linux since I version 9.1.
Both VIM and EMACS provide ways to enter unicode. VIM even supports
digraph input which would be particularly senseful in this case.

-- Christoph
Jan 24 '06 #21

P: n/a
Claudio Grondi wrote:
There is no symbol coming to my mind, but I would be glad if
it would express, that 'a' becomes a reference to a Python object being
currently referred by the identifier 'b' (maybe some kind of <-> ?).


With unicode, you have a lot of possibilities to express this:

a ← b # a = b
a ⇐ b # a = copy(b)
a ⇚ b # a = deepcopy(b)

-- Christoph
Jan 24 '06 #22

P: n/a
Dave Hansen wrote:
C uses ! as a unary logical "not" operator, so != for "not equal" just
seems to follow, um, logically.


Consequently, C should have used !> for <= and !< for >= ...

-- Christoph

Jan 24 '06 #23

P: n/a
Dave Hansen wrote:
Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?


The latter, IMHO. Especially variable names. Consider i vs. vs.
vs. vs. vs. ...


There could be conventions discouraging you to use ambiguous symbols.
Even today, you wouldn't use a lowercase "l" or an "O" because it can be
confused with a digit 1 or 0. But you're right this problem would become
much greater with unicode chars. This kind of pitfall has already been
overlooked with the introduction of international domain names which are
exploitable for phishing attacks...

-- Christoph
Jan 24 '06 #24

P: n/a
Christoph Zwerschke wrote:
Claudio Grondi wrote:
There is no symbol coming to my mind, but I would be glad if it would
express, that 'a' becomes a reference to a Python object being
currently referred by the identifier 'b' (maybe some kind of <-> ?).

With unicode, you have a lot of possibilities to express this:

a ← b # a = b
a ⇐ b # a = copy(b)
a ⇚ b # a = deepcopy(b)

^-- with this above also the notation

a ← b # a = b

starts to be obvious to me, as it covers also some of the specifics of
Python.

Nice idea.

Claudio

-- Christoph

Jan 24 '06 #25

P: n/a
Fredrik Lundh wrote:
umm. if you have an editor that can convert things back and forth, you
don't really need language support for "digraphs"...


It would just be very impractical to convert back and forth every time
you want to run a program. Python also supports tabs AND spaces though
you can easily convert things.

But indeed, in 100 years or so ;-) if people get accustomed to using
these symbols and input will be easy, digraph support could become
optional and then phase out... Just as now happens with C trigraphs.

-- Christoph

Jan 24 '06 #26

P: n/a
On Tue, 24 Jan 2006 19:44:28 +0100 in comp.lang.python, Christoph
Zwerschke <ci**@online.de> wrote:
Dave Hansen wrote:
C uses ! as a unary logical "not" operator, so != for "not equal" just
seems to follow, um, logically.


Consequently, C should have used !> for <= and !< for >= ...


Well, actually, no.

"Less (than) or equal" is <=. "Greater (than) or equal" is >=. "Not
equal" is !=.

If you want to write code for the IOCCC, you could use !(a>b) instead
of a<=b...

Regards,
-=Dave

--
Change is inevitable, progress is not.
Jan 24 '06 #27

P: n/a
On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:
The latter, IMHO. Especially variable names. Consider i vs. ì vs. *
vs. î vs. ï vs. ...


Agreed, but that's the programmer's fault for choosing stupid variable
names. (One character names are almost always a bad idea. Names which can
be easily misread are always a bad idea.) Consider how easy it is to
shoot yourself in the foot with plain ASCII:
l1 = 0
l2 = 4
....
pages of code
....
assert 11 + l2 = 4
--
Steven.

Jan 24 '06 #28

P: n/a
On Wed, 25 Jan 2006 08:26:16 +1100 in comp.lang.python, Steven
D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:
The latter, IMHO. Especially variable names. Consider i vs. vs.
vs. vs. vs. ...
Agreed, but that's the programmer's fault for choosing stupid variable
names. (One character names are almost always a bad idea. Names which can
be easily misread are always a bad idea.) Consider how easy it is to


I wasn't necessarily expecting single-character names. Indeed, the
different between i and is easier to see than the difference
between, say, long_variable_name and long_varable_name. For me,
anyway.
shoot yourself in the foot with plain ASCII:
l1 = 0
l2 = 4
...
pages of code
...
assert 11 + l2 = 4


You've shot yourself twice, there. Python would tell you about the
second error, though.

Regards,
-=Dave

--
Change is inevitable, progress is not.
Jan 24 '06 #29

P: n/a
On Tue, 24 Jan 2006 15:58:35 -0600, Dave Hansen wrote:
On Wed, 25 Jan 2006 08:26:16 +1100 in comp.lang.python, Steven
D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
On Tue, 24 Jan 2006 10:38:56 -0600, Dave Hansen wrote:
The latter, IMHO. Especially variable names. Consider i vs. ì vs. *
vs. î vs. ï vs. ...


Agreed, but that's the programmer's fault for choosing stupid variable
names. (One character names are almost always a bad idea. Names which can
be easily misread are always a bad idea.) Consider how easy it is to


I wasn't necessarily expecting single-character names. Indeed, the
different between i and ì is easier to see than the difference
between, say, long_variable_name and long_varìable_name. For me,
anyway.


Sure. But that's no worse than pxfoobrtnamer and pxfoobtrnamer.

I'm not saying that adding more characters to the mix won't increase the
opportunity to pick bad names. But this isn't a new problem, it is an old
problem.
shoot yourself in the foot with plain ASCII:
l1 = 0
l2 = 4
...
pages of code
...
assert 11 + l2 = 4


You've shot yourself twice, there.


Deliberately so. The question is, in real code without the assert, should
the result of the addition be 4, 12, 15 or 23?

--
Steven.

Jan 24 '06 #30

P: n/a
Robert Kern wrote:
James Stroud wrote:

I can't find "≤, ≥, or *" on my keyboard.

Get a better keyboard? or OS?


Please talk to my boss. Tell him I want a Quad G5 with about 2 Giga ram.
I'll by the keyboard myself, no problemo.
On OS X,

≤ is Alt-,
≥ is Alt-.
* is Alt-=

Fewer keystrokes than <= or >= or !=.


James
Jan 25 '06 #31

P: n/a
James Stroud wrote:
Robert Kern wrote:
James Stroud wrote:
I can't find "≤, ≥, or *" on my keyboard.


Get a better keyboard? or OS?


Please talk to my boss. Tell him I want a Quad G5 with about 2 Giga ram.
I'll by the keyboard myself, no problemo.


Alternatively, you can simply learn to use the tools in front of you.

http://www.cl.cam.ac.uk/~mgk25/unicode.html#input

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Jan 25 '06 #32

P: n/a
On Tue, 24 Jan 2006 04:09:00 +0100, Christoph Zwerschke <ci**@online.de> wrote:
On the page http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the language having the
following meaning:

<= >= !=

this should improve readibility (and make language more accessible to
beginners).

This should be an evolution similar to the digraphe and trigraph
(digramme et trigramme) from C and C++ languages."

How do people on this group feel about this suggestion?

The symbols above are not even latin-1, you need utf-8.
Maybe we need a Python unisource type which is abstract like unicode,
and through encoding can be rendered various ways. Of course it would have
internal representation in some encoding, probably utf-16le, but glyphs
for operators and such would be normalized, and then could be rendered
as multi-glyphs or special characters however desired. This means that
unisource would not just be an encoding resulting from decoding just
a character encoding like latin-1, but would be a result of decoding
source in a Python-syntax-sensitive way, differentiating between <=
as a relational operator vs '<=' in a string literal or comment etc.
(There are not many usefuls symbols in latin-1. Maybe one could use ×
for cartesian products...)

And while they are better readable, they are not better typable (at
least with most current editors).

Is this idea absurd or will one day our children think that restricting
to 7-bit ascii was absurd? I think it's important to have readable ascii representations available for
programming elements at least.
Are there similar attempts in other languages? I can only think of APL,
but that was a long time ago.

Once you open your mind for using non-ascii symbols, I'm sure one can
find a bunch of useful applications. Variable names could be allowed to
be non-ascii, as in XML. Think class names in Arabian... Or you could
use Greek letters if you run out of one-letter variable names, just as
Mathematicians do. Would this be desirable or rather a horror scenario?
Opinions?

I think there are pros and cons. What if the "href" in HTML could be spelled in
any characters? I.e., some things are part of a standard encoding and representation
system. Some of python is like that. "True" should not be spelled "Vrai" or "Sant," except
in localized messages, IMO, unless perhaps there is a unisource type that normalizes
these things too, and can render in localized formats. ... I guess China is a
pretty big market, so I wonder what they will do.

Someone has to get really excited about it, and have the expertise or willingness
to slog their way to expertise, and the persistence to get something done. And all
that in the face of the fact that much of the problem will be engineering consensus,
not engineering technical solutions. So are you excited? Good luck ;-)

Probably the best anyone with any excitement to spare could do is ask Martin
what he could use help with, if anything. He'd probably not like muddying any
existing clear visions and plans with impractical ramblings though ;-)

Regards,
Bengt Richter
Jan 25 '06 #33

P: n/a
I still remember it not being supported on most or all big Iron servers
at my previuos uni (were mostly SunOS, Digital UNIX among others)

Jan 25 '06 #34

P: n/a
Dave Hansen wrote:
C uses ! as a unary logical "not" operator, so != for "not equal" just
seems to follow, um, logically.

Pascal used <>, which intuitively (to me, anyway ;-) read "less than
or greater than," i.e., "not equal."


For quantitative data, anyway, or things which can be ordered consistently.

It's unclear to me how well this concept maps to other sorts of data.
Complex numbers, for example.

I think "not equal", at least the way our brains handle it in general,
is not equivalent to "less than or greater than".

That is, I think the concept "not equal" is less than or greater than
the concept "less than or greater than". <wink>

-Peter

Jan 25 '06 #35

P: n/a
On Wed, 25 Jan 2006 11:14:06 -0500, Peter Hansen wrote:
I think "not equal", at least the way our brains handle it in general,
is not equivalent to "less than or greater than".

That is, I think the concept "not equal" is less than or greater than
the concept "less than or greater than". <wink>


For objects that don't have total ordering, "not equal" != is not the
same as "less than or greater than" <>.

The two obvious examples are complex numbers, where C1 != C2 can be
evaluated, but C1 <> C2 is not defined, and NaNs, where NaN != NaN is
always true but NaN <> NaN is undefined.
--
Steven.

Jan 25 '06 #36

P: n/a
On Tue, 24 Jan 2006 04:09:00 +0100
Christoph Zwerschke <ci**@online.de> wrote:
On the page
http://wiki.python.org/moin/Python3%2e0Suggestions
I noticed an interesting suggestion:

"These operators ≤ ≥ * should be added to the
language having the following meaning:

<= >= !=

this should improve readibility (and make language more
accessible to beginners).

This should be an evolution similar to the digraphe and
trigraph (digramme et trigramme) from C and C++
languages."

How do people on this group feel about this suggestion?
In principle, and in the long run, I am definitely for it.

Pragmatically, though, there are still a lot of places
where it would cause me pain. For example, it exposes
problems even in reading this thread in my mail client
(which is ironic, considering that it manages to correctly
render Russian and Japanese spam messages. Grrr.).

OTOH, there will *always* be backwards systems, so you
can't wait forever to move to using newer features.
The symbols above are not even latin-1, you need utf-8. And while they are better readable, they are not better
typable (at least with most current editors).
They're not that bad. I manage to get kana and kanji working
correctly when I really need them.
Are there similar attempts in other languages? I can only
think of APL, but that was a long time ago.
I'm pretty sure that there are. The idea of adding UTF8 for
use in identifiers and stuff has been around for awhile for
Python. I'm pretty sure you can do this already in Java,
can't you? (I think I read this somewhere, but I don't
think it gets used much).
Once you open your mind for using non-ascii symbols, I'm
sure one can find a bunch of useful applications.
Variable names could be allowed to be non-ascii, as in
XML. Think class names in Arabian... Or you could use
Greek letters if you run out of one-letter variable names,
just as Mathematicians do. Would this be desirable or
rather a horror scenario? Opinions?


Greek letters would be a real relief in writing scientific
software. There's something deeply annoying about variables
named THETA, theta, and Theta. Or "w" meaning "omega.

People coming from other programming backgrounds may object
that these uses are less informative. But in the sciences,
some of these symbols have as much recognizability as "+" or
"$" do to other people. Reading math notation from a
scientists, I can be pretty darned certain that "c" is "the
speed of light" or that "epsilon" is a small, allowable
variation in a variable. And so on. It's true that there are
occasionable problems when problem domains merge, but that's
true of words, too.

It would also reduce the difficulty of going back and forth
between the paper describing the math, and the program
using it.

One thing that I also think would be good is to open up the
operator set for Python. Right now you can overload the
existing operators, but you can't easily define new ones.
And even if you do, you are very limited in what you can
use, and understandability suffers.

But unicode provides codeblocks for operators that
mathematicians use for special operators ("circle-times"
etc). That would both reduce confusion for people bothered
by weird choices of overloading "*" and "+" and allow people
who need these features the ability to use them.

It's also relevant that scientists in China and Saudi Arabia
probably use a roman "c" for the speed of light, or a "mu"
to represent a mass, so it's likely more understandable
internationally than using, say "lightspeed" and "mass".

OTOH, using identifiers in many different languages would
have the opposite effect. Right now, English is accepted as
a lingua franca for programming (and I admit that as a
native speaker of English, I benefit from that), but if it
became common practice to use lots of different languages,
cooperation might suffer.

But then, that's probably why English still dominates with
Java. I suspect that just means people wouldn't use it as
much. And I've certainly dealt with source code commented
in Spanish or German. It didn't kill me.

So, I'd say that in the long run:

1) Yes it will be adopted

2) The math and greek-letter type symbols will be the big
win

3) Localized variable names will be useful to some people,
but not widely popular, especially for cooperative free
software projects (of course, in the Far East, for example,
han character names might become very popular as they span
several languages). But I bet it will remain underused so
long as English remains the most popular international trade
language.

In the meantime, though, I predict many luddites will
scream "But it doesn't work on my vintage VT-220 terminal!"
(And I may even be one of them).

Cheers,
Terry

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 25 '06 #37

P: n/a
These were some interesting remarks, Terry.

I just asked myself how Chinese programmers feel about this. I don't
know Chinese, but probably they could write a whole program using only
one-character names for variables, and it would be still readable (at
least for Chinese)... Would this be used or would they rather prefer to
write in English on account of compatibilty issues (technical and human
readability in international projects) or because typing these chars is
more cumbersome than ascii chars? Any Chinese here?

-- Christoph
Jan 26 '06 #38

P: n/a
On Thu, 26 Jan 2006 01:12:10 -0600
Runsun Pan <py********@gmail.com> wrote:
For the tests that I tried earlier, using han characters
as the variable names doesn't seem to be possible (Syntax
Error) in python. I'd love to see if I can use han char
for all those keywords like import, but it doesn't work.
Yeah, I'm pretty sure we're talking about the future here.
:-)
That depends. People with ages in the middle or older
probably have very rare experience of typing han
characters. But with the popularity of computer
as well as the development of excellent input packages,
and most importantly,
the online-chats that many teenagers hooking to, next
several geneartions can type han char easily and
comfortably.
That's interesting. I think many people in the West tend to
imagine han/kanji characters as archaisms that will
disappear (because to most Westerners they seem impossibly
complex to learn and use, "not suited for the modern
world"). I used to think this was likely, although I always
thought the characters were beautiful, so it would be a
shame.

After taking a couple of semesters of Japanese, though, I've
come to appreciate why they are preferred. Getting rid of
them would be like convincing English people to kunvurt to
pur fonetik spelin'.

Which isn't happening either, I can assure you. ;-)
One thing that is lack in other languages is the "phrase
input"---- almost every
han input package provides this customizable feature. With
all these combined,
many of youngesters can type as fast as they talk. I
believe many of them input
han characters much faster than inputting English.
I guess this is like Canna/SKK server for typing Japanese.
I've never tried to localize my desktop to Japanese (and I
don't think I want to -- I can't read it all that well!),
but I've used kanji input in Yudit and a kanji-enabled
terminal.

I'm not sure I understand how this works, but surely if
Python can provide readline support in the interactive
shell, it ought to be able to handle "phrase input"/"kanji
input." Come to think of it, you probably can do this by
running the interpreter in a kanji terminal -- but Python
just doesn't know what to do with the characters yet.
The "side effect" of this technology advance might be that
in the future the
simplified chinese characters might deprecate, 'cos
there's no need to simplify
any more.


Heh. I must say the traditional characters are easier for
*me* to read. But that's probably because the Japanese kanji
are based on them, and that's what I learned. I never could
get the hang of "grass hand" or the "cursive" Chinese han
character style.

I would like to point out also, that as long as Chinese
programmers don't go "hog wild" and use obscure characters,
I suspect that I would have much better luck reading their
programs with han characters, than with, say, the Chinese
phonetic names! Possibly even better than what they thought
were the correct English words, if their English isn't that
good.

Cheers,
Terry

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Jan 26 '06 #39

P: n/a
Terry Hancock wrote:
One thing that I also think would be good is to open up the
operator set for Python. Right now you can overload the
existing operators, but you can't easily define new ones.
And even if you do, you are very limited in what you can
use, and understandability suffers.


One of the issues that would need to be dealt with in allowing new
operators to be defined is how to work out precedence rules for the new
operators. Right now you can redefine the meaning of addition and
multiplication, but you can't change the order of operations. (Witness
%, and that it must have the same precedence in both multiplication and
string replacement.)

If you allow (semi)arbitrary characters to be used as operators, some
scheme must be chosen for assigning a place in the precedence hierarchy.
Jan 26 '06 #40

P: n/a
Rocco Moretti wrote:
Terry Hancock wrote:
One thing that I also think would be good is to open up the
operator set for Python. Right now you can overload the
existing operators, but you can't easily define new ones.
And even if you do, you are very limited in what you can
use, and understandability suffers.

One of the issues that would need to be dealt with in allowing new
operators to be defined is how to work out precedence rules for the new
operators. Right now you can redefine the meaning of addition and
multiplication, but you can't change the order of operations. (Witness
%, and that it must have the same precedence in both multiplication and
string replacement.)

If you allow (semi)arbitrary characters to be used as operators, some
scheme must be chosen for assigning a place in the precedence hierarchy.


Speaking maybe only for myself:
I don't like implicit rules, so I don't like also any precedence
hierarchy being in action, so for safety reasons I always write even
8+6*2 (==20) as 8+(6*2) to be sure all will go the way I expect it.

Claudio
Jan 26 '06 #41

P: n/a
Claudio Grondi wrote:
Speaking maybe only for myself:
I don't like implicit rules, so I don't like also any precedence
hierarchy being in action, so for safety reasons I always write even
8+6*2 (==20) as 8+(6*2) to be sure all will go the way I expect it.


But for people who often use mathematical formulas this looks pretty
weird. If it wasn't a programming language, you wouldn't write an
asterik even, but either a mid dot or nothing. The latter is possible
because contrary to programming languages, you usually use one-letter
names in formulas, so it is clear that ab means a*b, and does not
designate a variable with the name "ab". x**2+y**2+(2*pi*r) looks way
uglier than x²+y²+2πr (another appication for greek letters). Maybe
providing a "formula" or "math style" mode would be sometimes helpful.
Or maybe not, because other conventions of mathematical formulas (long
fraction strokes, using subscript indices and superscript exponents
etc.) couldn't be solved so easily anyway. You would need editors with
the ability to display and input "formula sections" in Python programs
differently. Python would become something like "executable TeX" rather
than "executable pseudo code"...

-- Christoph
Jan 26 '06 #42

P: n/a
On Thu, 26 Jan 2006 17:47:51 +0100, Claudio Grondi <cl************@freenet.de> wrote:
Rocco Moretti wrote:
Terry Hancock wrote:
One thing that I also think would be good is to open up the
operator set for Python. Right now you can overload the
existing operators, but you can't easily define new ones.
And even if you do, you are very limited in what you can
use, and understandability suffers.

One of the issues that would need to be dealt with in allowing new
operators to be defined is how to work out precedence rules for the new
operators. Right now you can redefine the meaning of addition and
multiplication, but you can't change the order of operations. (Witness
%, and that it must have the same precedence in both multiplication and
string replacement.)

If you allow (semi)arbitrary characters to be used as operators, some
scheme must be chosen for assigning a place in the precedence hierarchy.


Speaking maybe only for myself:
I don't like implicit rules, so I don't like also any precedence
hierarchy being in action, so for safety reasons I always write even
8+6*2 (==20) as 8+(6*2) to be sure all will go the way I expect it.

Maybe you would like the unambiguousness of
(+ 8 (* 6 2))
or
6 2 * 8 +
?

Hm, ... ISTM you could have a concept of all objects as potential operator
objects as now, but instead of selecting methods of the objects according
to special symbols like + - * etc, allow method selection by rules applied
to a sequence of objects for selecting methods. E.g., say
a, X, b, Y, c
is a sequence of objects (happening to be contained in a tuple expression here).
Now let's define seqeval such that
seqeval((a, X, b, Y, c))
looks at the objects to see if they have certain methods, and then calls some of
those methods with some of the other objects as arguments, and applies rules of
precedence and association to do something useful, producing a final result.

I'm just thinking out loud here, but what I'm getting at is being able to write
8+6*2
as
seqeval((8, PLUS, 6, TIMES, 2))
with the appropriate definitions of seqeval and PLUS and TIMES. This is with a view
to having seqeval as a builtin that does standard processing, and then having
a language change to make white-space-separated expressions like
8 PLUS 6 TIMES 2
be syntactic sugar for an implicit
seqeval((8, PLUS, 6, TIMES, 2))
where PLUS and TIMES may be arbitrary user-defined objects suitable for seqeval.
I'm thinking out loud, so I anticipate syntactic ambiguities in expressions and the need to
use parens etc., but this would in effect let us define arbitrarily named operators.
Precedence might be established by looking for PLUS.__precedence__. But as usual,
parens would control precedence dominantly. E.g.,
(8 PLUS 6) TIMES 2
would be sugar for
seqeval((seqeval(8, PLUS, 6), TIMES, 2)

IOW, we have an object sequence expression analogous to a tuple expression without commas.
I guess generator expressions might be somewhat of a problem to disambiguate sometimes, we'll see
how bad that gets ;-)

One way to detect operator objects would be to test callable(obj), which would allow
for functions and types and bound methods etc. Now there needs to be a way of
handling UNARY_PLUS vs PLUS functionality (obviously the name bindings are just mnemonic
and aren't seen by seqeval unless they're part of the operator object). ...

A sketch:
def seqeval(objseq): ... """evaluate an object sequence. rules tbd."""
... args=[]
... ops=[]
... for obj in objseq:
... if callable(obj):
... if ops[-1:] and obj.__precedence__<= ops[-1].__precedence__:
... args[-2:] = [ops.pop()(*args[-2:])]
... ops.append(obj)
... continue
... elif isinstance(obj, tuple):
... obj = seqeval(obj)
... while len(args)==0 and ops: # unary
... obj = ops.pop()(obj)
... args.append(obj)
... while ops:
... args[-2:] = [ops.pop()(*args[-2:])]
... return args[-1]
... def PLUS(x, y=None): ... print 'PLUS(%s, %s)'%(x,y)
... if y is None: return x
... else: return x+y
... PLUS.__precedence__ = 1

def MINUS(x, y=None): ... print 'MINUS(%s, %s)'%(x,y)
... if y is None: return -x
... else: return x-y
... MINUS.__precedence__ = 1

def TIMES(x, y): ... print 'TIMES(%s, %s)'%(x,y)
... return x*y
... TIMES.__precedence__ = 2

seqeval((8, PLUS, 6, TIMES, 2)) TIMES(6, 2)
PLUS(8, 12)
20 seqeval(((8, PLUS, 6), TIMES, 2)) PLUS(8, 6)
TIMES(14, 2)
28 seqeval(((8, PLUS, 6), TIMES, (MINUS, 2))) PLUS(8, 6)
MINUS(2, None)
TIMES(14, -2)
-28 seqeval((MINUS, (8, PLUS, 6), TIMES, (MINUS, 2))) PLUS(8, 6)
MINUS(14, None)
MINUS(2, None)
TIMES(-14, -2)
28 list(seqeval((i, TIMES, j, PLUS, k)) for i in (2,3) for j in (10,100) for k in (5,7))

TIMES(2, 10)
PLUS(20, 5)
TIMES(2, 10)
PLUS(20, 7)
TIMES(2, 100)
PLUS(200, 5)
TIMES(2, 100)
PLUS(200, 7)
TIMES(3, 10)
PLUS(30, 5)
TIMES(3, 10)
PLUS(30, 7)
TIMES(3, 100)
PLUS(300, 5)
TIMES(3, 100)
PLUS(300, 7)
[25, 27, 205, 207, 35, 37, 305, 307]

Regards,
Bengt Richter
Jan 27 '06 #43

P: n/a
Bengt Richter wrote:
On Thu, 26 Jan 2006 17:47:51 +0100, Claudio Grondi <cl************@freenet.de> wrote:

Rocco Moretti wrote:
Terry Hancock wrote:
One thing that I also think would be good is to open up the
operator set for Python. Right now you can overload the
existing operators, but you can't easily define new ones.
And even if you do, you are very limited in what you can
use, and understandability suffers.
One of the issues that would need to be dealt with in allowing new
operators to be defined is how to work out precedence rules for the new
operators. Right now you can redefine the meaning of addition and
multiplication, but you can't change the order of operations. (Witness
%, and that it must have the same precedence in both multiplication and
string replacement.)

If you allow (semi)arbitrary characters to be used as operators, some
scheme must be chosen for assigning a place in the precedence hierarchy.


Speaking maybe only for myself:
I don't like implicit rules, so I don't like also any precedence
hierarchy being in action, so for safety reasons I always write even
8+6*2 (==20) as 8+(6*2) to be sure all will go the way I expect it.


Maybe you would like the unambiguousness of
(+ 8 (* 6 2))
or
6 2 * 8 +
?

Hm, ... ISTM you could have a concept of all objects as potential operator
objects as now, but instead of selecting methods of the objects according
to special symbols like + - * etc, allow method selection by rules applied
to a sequence of objects for selecting methods. E.g., say
a, X, b, Y, c
is a sequence of objects (happening to be contained in a tuple expression here).
Now let's define seqeval such that
seqeval((a, X, b, Y, c))
looks at the objects to see if they have certain methods, and then calls some of
those methods with some of the other objects as arguments, and applies rules of
precedence and association to do something useful, producing a final result.

I'm just thinking out loud here, but what I'm getting at is being able to write
8+6*2
as
seqeval((8, PLUS, 6, TIMES, 2))
with the appropriate definitions of seqeval and PLUS and TIMES. This is with a view
to having seqeval as a builtin that does standard processing, and then having
a language change to make white-space-separated expressions like
8 PLUS 6 TIMES 2
be syntactic sugar for an implicit
seqeval((8, PLUS, 6, TIMES, 2))
where PLUS and TIMES may be arbitrary user-defined objects suitable for seqeval.
I'm thinking out loud, so I anticipate syntactic ambiguities in expressions and the need to
use parens etc., but this would in effect let us define arbitrarily named operators.
Precedence might be established by looking for PLUS.__precedence__. But as usual,
parens would control precedence dominantly. E.g.,
(8 PLUS 6) TIMES 2
would be sugar for
seqeval((seqeval(8, PLUS, 6), TIMES, 2)

IOW, we have an object sequence expression analogous to a tuple expression without commas.
I guess generator expressions might be somewhat of a problem to disambiguate sometimes, we'll see
how bad that gets ;-)

One way to detect operator objects would be to test callable(obj), which would allow
for functions and types and bound methods etc. Now there needs to be a way of
handling UNARY_PLUS vs PLUS functionality (obviously the name bindings are just mnemonic
and aren't seen by seqeval unless they're part of the operator object). ...

A sketch:
>>> def seqeval(objseq): ... """evaluate an object sequence. rules tbd."""
... args=[]
... ops=[]
... for obj in objseq:
... if callable(obj):
... if ops[-1:] and obj.__precedence__<= ops[-1].__precedence__:
... args[-2:] = [ops.pop()(*args[-2:])]
... ops.append(obj)
... continue
... elif isinstance(obj, tuple):
... obj = seqeval(obj)
... while len(args)==0 and ops: # unary
... obj = ops.pop()(obj)
... args.append(obj)
... while ops:
... args[-2:] = [ops.pop()(*args[-2:])]
... return args[-1]
... >>> def PLUS(x, y=None): ... print 'PLUS(%s, %s)'%(x,y)
... if y is None: return x
... else: return x+y
... >>> PLUS.__precedence__ = 1
>>>
>>> def MINUS(x, y=None): ... print 'MINUS(%s, %s)'%(x,y)
... if y is None: return -x
... else: return x-y
... >>> MINUS.__precedence__ = 1
>>>
>>> def TIMES(x, y): ... print 'TIMES(%s, %s)'%(x,y)
... return x*y
... >>> TIMES.__precedence__ = 2
>>>
>>> seqeval((8, PLUS, 6, TIMES, 2)) TIMES(6, 2)
PLUS(8, 12)
20 >>> seqeval(((8, PLUS, 6), TIMES, 2)) PLUS(8, 6)
TIMES(14, 2)
28 >>> seqeval(((8, PLUS, 6), TIMES, (MINUS, 2))) PLUS(8, 6)
MINUS(2, None)
TIMES(14, -2)
-28 >>> seqeval((MINUS, (8, PLUS, 6), TIMES, (MINUS, 2))) PLUS(8, 6)
MINUS(14, None)
MINUS(2, None)
TIMES(-14, -2)
28 >>> list(seqeval((i, TIMES, j, PLUS, k)) for i in (2,3) for j in (10,100) for k in (5,7))

TIMES(2, 10)
PLUS(20, 5)
TIMES(2, 10)
PLUS(20, 7)
TIMES(2, 100)
PLUS(200, 5)
TIMES(2, 100)
PLUS(200, 7)
TIMES(3, 10)
PLUS(30, 5)
TIMES(3, 10)
PLUS(30, 7)
TIMES(3, 100)
PLUS(300, 5)
TIMES(3, 100)
PLUS(300, 7)
[25, 27, 205, 207, 35, 37, 305, 307]

Regards,
Bengt Richter

At the first glance I like this concept much and mean it is very
Pythonic in the sense of the term as I understand it. I would be glad to
see it implemented if it does not result in any side effects or other
problems I can't currently anticipate.

Claudio
Jan 27 '06 #44

P: n/a
Terry Hancock wrote:
That's interesting. I think many people in the West tend to
imagine han/kanji characters as archaisms that will
disappear (because to most Westerners they seem impossibly
complex to learn and use, "not suited for the modern
world"). I don't know about "the West". Isn't it more typical for the
US that people believe that "everybody really wants to be like
us". Here in Sweden, *we* obviously want to be like you, even
if we don't admit it openly, but we don't suffer from the
misconception that this applies to all of the world. ;)
After taking a couple of semesters of Japanese, though, I've
come to appreciate why they are preferred. Getting rid of
them would be like convincing English people to kunvurt to
pur fonetik spelin'.

Which isn't happening either, I can assure you. ;-) The Germans just had a spelling reform. Norway had a major
language reform in the mid 19th century to get rid of the old
Danish influences (and still have two completely different ways
of spelling everything). You never know what will happen. You
are also embracing the metric system, inch by inch... ;)

Actually, it seems that recent habit of sending text messages
via mobile phones is the prime driver for reformed spelling
these days.
I'm not sure I understand how this works, but surely if
Python can provide readline support in the interactive
shell, it ought to be able to handle "phrase input"/"kanji
input." Come to think of it, you probably can do this by
running the interpreter in a kanji terminal -- but Python
just doesn't know what to do with the characters yet. I'm sure the same principles could be used to make a very fast
and less misspelling prone editing environment though. That
could actually be a reason to step away from vi or Emacs (but
I assume it would soon work in Emacs too...)
I would like to point out also, that as long as Chinese
programmers don't go "hog wild" and use obscure characters,
I suspect that I would have much better luck reading their
programs with han characters, than with, say, the Chinese
phonetic names! Possibly even better than what they thought
were the correct English words, if their English isn't that
good.

You certainly have a point there. Even when I don't work in an
English speaking environment as I do now, I try to write all
comments and variable names etc in English. You never know when
you need to show a code snippet to people who don't read Swedish.
Also, ASCII lacks three of our letters and properly translated
is often better than written with the wrong letters.

On the other hand, if the target users describe their problem
domain with e.g. a Swedish terminology, translating all terms
will take time and increase confusion. Also, there are plenty
of programmers who don't write English so well...
Jan 27 '06 #45

P: n/a
Just a couple half-serious responses to your comment...

On Fri, 27 Jan 2006 11:05:15 +0100 in comp.lang.python, Magnus Lycka
<ly***@carmen.se> wrote:
Terry Hancock wrote:
That's interesting. I think many people in the West tend to
imagine han/kanji characters as archaisms that will
disappear (because to most Westerners they seem impossibly
complex to learn and use, "not suited for the modern
world").

I don't know about "the West". Isn't it more typical for the
US that people believe that "everybody really wants to be like
us". Here in Sweden, *we* obviously want to be like you, even
if we don't admit it openly, but we don't suffer from the
misconception that this applies to all of the world. ;)


1) Actually, we don't think "everyone wants to be like us." More like
"anyone who doesn't want to be like us is weird."

2) This extends to our own fellow citizens.

Regards,
-=Dave

--
Change is inevitable, progress is not.
Jan 27 '06 #46

P: n/a
On Fri, 27 Jan 2006 08:11:24 GMT in comp.lang.python, bo**@oz.net
(Bengt Richter) wrote:

[...]
Maybe you would like the unambiguousness of
(+ 8 (* 6 2))
or
6 2 * 8 +
?


Well, I do like lisp and Forth, but would prefer Python to remain
Python.

Though it's hard to fit Python into 1k on an 8-bit mocrocontroller...

Regards,
-=Dave

--
Change is inevitable, progress is not.
Jan 27 '06 #47

P: n/a
On 1/27/06, Magnus Lycka <ly***@carmen.se> wrote:
After taking a couple of semesters of Japanese, though, I've
come to appreciate why they are preferred. Getting rid of
them would be like convincing English people to kunvurt to
pur fonetik spelin'.

Which isn't happening either, I can assure you. ;-) The Germans just had a spelling reform. Norway had a major
language reform in the mid 19th century to get rid of the old
Danish influences (and still have two completely different ways
of spelling everything). You never know what will happen. You
are also embracing the metric system, inch by inch... ;)


The simplified chinese exists due to the call for modernization of
language decades ago. That involved the 'upside-down' of almost
entire culture --- nowadays people in China can't even read most of
the documents written just 70~80 years ago. Imagine its damage
to the 'historical sense' of modern chinese !!! The "anti-simplification"
force was thus imaginaribly huge. Actually, not only the original
plan of simplification wasn't completed (only proceded to the 1st
stage; the 2nd stage was put off), there are calls for reversal -- back
to the traditional forms -- lately. Obviously, language reform is not
trivial; Especially, for asian countries, it is probably not as easy as it
is for western countries.

China is still a central authoritarian country. Even with that government
they were unable to push this thru. If any one would even dream about
language reform in democratic Taiwan, I bet the proposal won't even
pass the first step in the congress.
Actually, it seems that recent habit of sending text messages
via mobile phones is the prime driver for reformed spelling
these days.


Well, to solve the problem you can either (1) reform the spelling
of a language to meet the limitation of mobile phones, or (2)
advancing the input device on the mobile phones such that they
can input the language of your choice. For most asian languages,
(1) is certainly out of question.
I'm not sure I understand how this works, but surely if
Python can provide readline support in the interactive
shell, it ought to be able to handle "phrase input"/"kanji
input." Come to think of it, you probably can do this by
running the interpreter in a kanji terminal -- but Python
just doesn't know what to do with the characters yet.

I'm sure the same principles could be used to make a very fast
and less misspelling prone editing environment though. That
could actually be a reason to step away from vi or Emacs (but
I assume it would soon work in Emacs too...)


True. Actually Google, Answers.com and some other desktop
applications use 'auto-complete' feature already. It might seem
impressive to most western users but, from where I was from
(Taiwan), this 'phrase-input', as well as "showing up in the order
of the most-frequently-use for any specific user", have been
around for about 20 years.
I would like to point out also, that as long as Chinese
programmers don't go "hog wild" and use obscure characters,
I suspect that I would have much better luck reading their
programs with han characters, than with, say, the Chinese
phonetic names! Possibly even better than what they thought
were the correct English words, if their English isn't that
good.

You certainly have a point there. Even when I don't work in an
English speaking environment as I do now, I try to write all
comments and variable names etc in English. You never know when
you need to show a code snippet to people who don't read Swedish.
Also, ASCII lacks three of our letters and properly translated
is often better than written with the wrong letters.


If there will be someday that any programming language can
be input with some form like Big5, I believe its intended target
will ONLY be people using only Big5. That means, if it exists, the
chance of showing it to other-language-users probably be extremely
nil, Think about this: there are still a whole lot of people who don't
know English at all. If no such a 'Big5-specific' programming
tool around, their chances of learning programming is completely
rid off.

--
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~
Runsun Pan, PhD
py********@gmail.com
Nat'l Center for Macromolecular Imaging
http://ncmi.bcm.tmc.edu/ncmi/
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~
Jan 27 '06 #48

P: n/a
Robert Kern wrote:
On OS X,

≤ is Alt-,
≥ is Alt-.
* is Alt-=


Thumbs up on the unicode idea, but national keyboards (i.e. non-english)
have already used almost every possible
not-strictly-defined-in-EN-keyboards combination of keys for their own
characters. In particular, the key combinations above are reprogrammed
to something else in my language/keyboard.

But, the idea that Python could be made ready for when the keyboards and
editors start supporting such characters is a good one (i.e. keep both
<= and ≤ for several decades).

It's not a far-out idea. I stumbled about a year ago on a programming
language that INSISTED on unicode characters like ≤ as well as the rest
of mathematical/logical symbols; I don't remember its name but the
source code with characters like that looked absolutely beautiful. I
suppose that one day, when unicode becomes more used than ascii7, "old"
code like current C and python will be considered ugly and unelegant in
appearance :)
Jan 27 '06 #49

P: n/a
Ivan Voras wrote:
It's not a far-out idea. I stumbled about a year ago on a programming
language that INSISTED on unicode characters like ≤ as well as the rest
of mathematical/logical symbols; I don't remember its name but the
source code with characters like that looked absolutely beautiful.


Could it be APL?

http://en.wikipedia.org/wiki/APL_programming_language

Although saying it used "Unicode characters" is a bit of a stretch - APL
predated Unicode by some 30+ years.
Jan 27 '06 #50

61 Replies

This discussion thread is closed

Replies have been disabled for this discussion.