Why prefer != over <> for Python 3.0?

[hdante]

Hallöchen!



It *is* implemented in Emacs. You can even choose from many input
methods, optimised for differend areas/languages.

I mean creating an input method specific for programming languages,
not using the TeX one.

 

[Dennis Lee Bieber]

I prefer <> but I feel that it's better

It's much faster to type: hold the left shift, bounce the , and .
keys...

Versus: hold the right shift, stretch to the 1, release the shift,
swap hands and stretch to the =...
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Bjoern Schliessmann]

Emacs is generally not regarded as being convenient, however, it
has very strong input methods. I type "\gtrless" and get "?",
or "\forall" and get "?".

I wonder where the point of this is. Why use fancy unicode chars
if they're not better to read (apart from not being readable with
every font) and require at least the same amount of keypresses?

Regards,


Björn

 

[Torsten Bronger]

Hallöchen!


Doesn't KNode support UTF-8?

I wonder where the point of this is. Why use fancy unicode
chars if they're not better to read (apart from not being readable
with every font) and require at least the same amount of
keypresses?

Who wants to minimize the number of keypresses? We're not Perl
after all. ;-)

As a general rule of thumb in typography, more glyph forms increase
readability. APL is not readable at all but this is due to its
syntax I suppose. I find hdante's excerpt very readable.

The only reason why we don't use those special characters is that
they aren't ASCII. While ∀ or ∈ are questionable because Python
prefers English words instead of scientific symbols, ≠ or ≤ would be
certainly more legible than != or <=. But they are not ASCII, so
there is no net benefit.

However, I'm quite sure that when Unicode has arrived almost
everywhere, some languages will start considering such characters in
their core syntax. Python 3.0 allows for Unicode letters in
identifiers, and there's still room for improvement.

Tschö,
Torsten.

 

[Paul Rubin]

However, I'm quite sure that when Unicode has arrived almost
everywhere, some languages will start considering such characters in
their core syntax. Python 3.0 allows for Unicode letters in
identifiers, and there's still room for improvement.

I agree. What's the codepoint for lower case lambda?

 

[Bjoern Schliessmann]

Doesn't KNode support UTF-8?

Well, it should, but automatic encoding detection doesn't always
seem to work (or does it even have one?). I'm looking for a
different (faster) newsreader anyway.

Who wants to minimize the number of keypresses? We're not Perl
after all. ;-)

Sure, but I also don't want to enter fancy unicode operators. I'm
using Python on some computers that even don't support unicode.

However, I'm quite sure that when Unicode has arrived almost
everywhere, some languages will start considering such characters
in their core syntax.

This should be the time when there are widespread quasi-standardised
input methods for those characters.

Regards,


Björn

 

[Terry Reedy]

in message | > However, I'm quite sure that when Unicode has arrived almost
| > everywhere, some languages will start considering such characters
| > in their core syntax.
|
| This should be the time when there are widespread quasi-standardised
| input methods for those characters.

C has triglyphs for keyboards missing some ASCII chars. != and <= could
easily be treated as diglyphs for the corresponding chars. In a sense they
are already, it is just that the real things are not allowed ;=).

 

[Gabriel Genellina]

"Bjoern Schliessmann" <[email protected]>
wrote
in message | > However, I'm quite sure that when Unicode has arrived almost
| > everywhere, some languages will start considering such characters
| > in their core syntax.
|
| This should be the time when there are widespread quasi-standardised
| input methods for those characters.

C has triglyphs for keyboards missing some ASCII chars. != and <= could
easily be treated as diglyphs for the corresponding chars. In a sense
they
are already, it is just that the real things are not allowed ;=).

I think it should be easy to add support for ≠≤≥ and even λ, only the
tokenizer has to be changed.

 

[Gabriel Genellina]

as for the original question, the point of going unicode is not to
make code unicode, but to make code's output unicode. thin of print
calls and templates and comments the world's complexity in languages.
sadly most english speaking people think unicode is irrelevant because
ASCII has everything, but their narrow world is what's wrong.

Python 3 is a good step in that direction. Strings are unicode,
identifiers are not restricted to ASCII, and the default source encoding
is not ASCII anymore (but I don't remember which one).
So this is now possible with 3.0:
b'halag\xfce\xf1o'

 

[Steve Holden]

Hallöchen!

[...]

I think it should be easy to add support for ≠≤≥ and even λ,
only the tokenizer has to be changed.

show me a keyboard that has those symbols and I'm all up for it.

For <= I have to press three buttons, for ≤ I have to press four
buttons. Not much of a difference. ;-)

However, I'm slightly disappointed with the UTF-8 support in some
mail clients involved in this thread, so Unicode surely has not
arrived yet.

I'd settle for a program listing utility that made the replacements.

regards
Steve

 

[Steve Holden]

Hallöchen!

[...]

I think it should be easy to add support for ≠≤≥ and even λ,
only the tokenizer has to be changed.

show me a keyboard that has those symbols and I'm all up for it.

For <= I have to press three buttons, for ≤ I have to press four
buttons. Not much of a difference. ;-)

However, I'm slightly disappointed with the UTF-8 support in some
mail clients involved in this thread, so Unicode surely has not
arrived yet.

I'd settle for a program listing utility that made the replacements.

regards
Steve

 

[John J. Lee]

Wow, APL on 8 bits?
Now there is (or perhaps there was) J, a reincarnation of APL by
Iverson himself that uses ASCII characters only.

The BBC Model B ran I-APL, too.

Sitting on my desk is a copy of "I-APL Instruction Manual for PC
Clones, RML Nimbus, BBC Master & B, and Archimedes", along with a few
other APL books and a pile of newsletters, waiting to be thrown away
:-( I got a copy because they were giving it away free to schools.
Poisoning young minds ;-)

How did programmers manage back then in 32k? Less software
development, more jigsaw puzzle.


John

 

[MRAB]

En Sun, 30 Mar 2008 11:10:20 -0300, MRAB <[email protected]>
escribió:





Wow, APL on 8 bits?
Now there is (or perhaps there was) J, a reincarnation of APL by Iverson
himself that uses ASCII characters only.

The Sinclair QL used the Motorola 68008, which was like the 68000 (a
32-bit processor) but with an 8-bit external data bus instead of a 16-
bit one; that made the system cheaper to build, but as the
instructions were multiples of 16 bits long every instruction required
at least 2 memory accesses, which made it slower. Nice clean processor
though, unlike the 8086...

 

[Tim Roberts]

How did programmers manage back then in 32k? Less software
development, more jigsaw puzzle.

Yes, indeed. In response to a challenge posted on one of the x86 assembler
newsgroups about two years ago, one intrepid Russian programmer produced a
generic Sudoku solver in a 65-byte executable. Yes, that's 65 BYTES -- not
KB, not MB.

I consider myself an x86 assembler expert, but I remain in awe of that
code.

 

[D'Arcy J.M. Cain]

Yes, indeed. In response to a challenge posted on one of the x86 assembler
newsgroups about two years ago, one intrepid Russian programmer produced a
generic Sudoku solver in a 65-byte executable. Yes, that's 65 BYTES -- not
KB, not MB.

Wow! I would have thought that the header on most executible file
formats was bigger than that these days. Or was this done as a .COM
file or something like that?