Why prefer != over <> for Python 3.0?
kwit...@telenet.be
Python 3.0, or if there have been any meaningful discussions posted
before (hard to search google with '<>' keyword), but why would anyone
prefer the comparison operator != over <>???
I've written an article about it to try and save this nice "is not
equal" operator, located at http://dewitters.koonsolo.com/python_neq.html
Please set it straight in 3.0, and if not, convince me with a good
reason of doing so, so that I can live with it and don't have to spend
the rest of my life in 2.x ;).
Paul Rubin
> I don't know if this is the right place to discuss the death of <> in
> Python 3.0, or if there have been any meaningful discussions posted
> before (hard to search google with '<>' keyword), but why would anyone
> prefer the comparison operator != over <>???
I doubt anyone cares. Python probably chose != because it's what C uses.
The scary choice is /= which can be interpreted as an assignment. Python
lacks assignment expressions partly because of a meme that using = instead
of == by accident is a common C bug. I'm sure it happens but at least in
my own experience (from having written plenty of buggy C code over the
years) it's not that frequent. Using /= instead of != seems more likely,
for programmers who switch between C and languages that use /= for nonequality.
Steven D'Aprano
> kwit...@telenet.be writes:
>> I don't know if this is the right place to discuss the death of <> in
>> Python 3.0, or if there have been any meaningful discussions posted
>> before (hard to search google with '<>' keyword), but why would anyone
>> prefer the comparison operator != over <>???
>
> I doubt anyone cares.
[channeling Luke Skywalker sotto voice]
I care.
> Python probably chose != because it's what C uses.
Coming from a background in Pascal, I originally hated the look of != and
preferred <> but I've now got used to the look of it.
When I design my own language (ha!), I'll use != for "not equal to" and
reserve <> for "greater than or less than but not equal to" which is
subtly different. (Think about unordered values, where x != y does not
imply that x < y or x > y, e.g. IEEE NaNs.)
> The scary choice is /= which can be interpreted as an assignment.
"Can be"?
>>> x = 5.0
>>> x /= 2
>>> x
2.5
Koen, I've read your blog and I'm afraid that your reasoning is specious.
You say:
[quote]
For comparison (not assignment!), they use operators like <, >, <=
(smaller or equals), >= (larger or equals), == (double '=' so there is no
confusion with assignment).
All pretty clear hey? But now comes the catch, there exists an operator
!=... but what does it mean? Well, that one is pretty easy, of course !
must be an operator of its own (in non-python languages meaning 'not'),
and it resembles the fancy assignment statement, so
a != b
must mean "assign the value 'not b' to 'a'... right?... Wrong! Somehow
this is a comparison operator meaning "not equals"... what??? Yes, that's
right, but hey, you learn to live with it eventually.
[end quote]
Given that <= is a comparison operator, not an assignment, why do you
jump to the conclusion that != is an assignment? Why don't you argue that
"x <= y" means "assign the value of x<y to x"?
Since you jump to an invalid conclusion about !=, the rest of your
argument fails.
--
Steven
Paul Rubin
> reserve <> for "greater than or less than but not equal to" which is
> subtly different. (Think about unordered values, where x != y does not
> imply that x < y or x > y, e.g. IEEE NaNs.)
Heh, good point.
> > The scary choice is /= which can be interpreted as an assignment.
> "Can be"?
Yes, what I mean is that some languages (e.g. Ada, Haskell) use /= for
nonequality. So if you switch between Haskell and C, you could find
yourself typing /= when you mean != and the compiler won't flag it.
Jeroen Ruigrok van der Werven
>Yes, what I mean is that some languages (e.g. Ada, Haskell) use /= for
>nonequality.
/= is understandable given how it looks like a digraph for ≠ (U+2260) and I
am guessing that was the intent.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae..?
Lie
> I don't know if this is the right place to discuss the death of <> in
> Python 3.0, or if there have been any meaningful discussions posted
> before (hard to search google with '<>' keyword), but why would anyone
> prefer the comparison operator != over <>???
>
> I've written an article about it to try and save this nice "is not
>
> Please set it straight in 3.0, and if not, convince me with a good
> reason of doing so, so that I can live with it and don't have to spend
> the rest of my life in 2.x ;).
<quote who=OP's blog>
All pretty clear hey? But now comes the catch, there exists an
operator !=... but what does it mean? Well, that one is pretty easy,
of course ! must be an operator of its own (in non-python languages
meaning 'not'), and it resembles the fancy assignment statement
<...snip...>
When I started to learn python I came across an operator <>. What
could it mean? Well, you don't have to think long about it. You're
only reference are the < and > operators (with meanings the same as in
mathematics or plain written language, any non programmer would
understand this). So <> must mean "smaller or larger", or not-equals,
no question about that. It couldn't possible be mistaken as an
assignment operator. You just have to love a language that uses
operators with clear and obvious meaning.
</quote>
You're forcing your argument too much, both != and <> are NOT standard
mathematics operators -- the standard not-equal operator is >< -- and
I can assure you that both != and <> won't be comprehensible to non-
programmers. And I'm not sure if anyone could have mistaken != for
assignment operator because they're used in completely different
places (which is the reason why some languages can use the same
operator for = (assignment) and == (comparison)). = is always used in
a line by itself while != is always used in places where a
'condition' (a.k.a. 'expression') is required.
The problem you stated may be a problem in C/C++ (if C/C++ do have
both != and <>, fortunately they only have !=) because C/C++'s =
(assignment) is an operator and operators always return a value but in
Python = (assignment) is a statement and can't return a value so "if a
= b:" always raise an error.
Since != operator can only be used in places where a
'condition'/'expression' is required and never in a line by itself as
a statement, it could never be mistaken as an assignment (which is a
statement).
The problem just don't exist in Python.
Duncan Booth
> You're forcing your argument too much, both != and <> are NOT standard
> mathematics operators -- the standard not-equal operator is >< -- and
> I can assure you that both != and <> won't be comprehensible to non-
> programmers.
My maths may be a bit rusty, but I always thought that the standard not-
equal operator was like an = sign but with a diagonal slash through it as
displayed when you do:
print u'\u2260'
Lie
Ah yes, that is also used (I completely forgot about that one, my
math's aren't that sharp anymore) and I think it's used more
frequently than ><. Some books use >< while most use ≠, but my
argument was that no math book use != or <> (except in math for
programmers).
Carl Banks
> why would anyone
Questions that begin with the words "why would anyone" are almost
always betray an arrogance about their own beliefs and an ignorance
(or feigning ignorance) of human nature.
Wiser folks know better than to phrase this question so judgmentally.
> Please set it straight in 3.0, and if not, convince me with a good
> reason of doing so, so that I can live with it and don't have to spend
> the rest of my life in 2.x ;).
1. It's not going to change in Python 3.0.
2. It's a silly thing to care so much about that you will avoid using
a langauge because of it.
Carl Banks
Dan Bishop
> kwitt...@telenet.be writes:
> > I don't know if this is the right place to discuss the death of <> in
> > Python 3.0, or if there have been any meaningful discussions posted
> > before (hard to search google with '<>' keyword), but why would anyone
> > prefer the comparison operator != over <>???
>
> I doubt anyone cares. Python probably chose != because it's what C uses.
MOST of Python's operators are based on C's. Consider, for example,
the bitwise operators | ^ & << >> ~ and the compound assignment
operators += -= etc.
The exceptions are ** (from Fortran), //, and the logical operators.
Gabriel Genellina
<michael...@gmail.com> escribió:
> to me it seems simple.
>
> C uses !=
>
> why does C use != .... because its kind of hard to type the "equal with a
> slash"
In C, ! by itself is the logical "not", so !(a==b) is the same as (a!=b)
and that's rather consistent.
Python doesn't use ! for anything else; != is rather arbitrary but
certainly much better than <> (for many objects < and > are meaningless;
being equal or not equal has nothing to do with being less or greater)
--
Gabriel Genellina
Steven D'Aprano
>> Please set it straight in 3.0, and if not, convince me with a good
>> reason of doing so, so that I can live with it and don't have to spend
>> the rest of my life in 2.x ;).
>
> 1. It's not going to change in Python 3.0.
>
> 2. It's a silly thing to care so much about that you will avoid using a
> langauge because of it.
I dislike the attitude that "oh, feature X is unimportant, why should we
care about it?". It's often -- but not always -- said by those who do
care very much about it themselves, except they prefer the way it is
rather then the requested feature.
If Guido had a sudden brain tumor and replaced comparison operators with
Fortran-style operators, it wouldn't destroy Python. It would just be a
minor wart on an otherwise good language. So why should we care about
using == instead of .EQ.?
Why does Python use # for comments instead of Basic-style remarks? Would
it be silly to care if Python 3 discarded # and introduced REM?
I could belabor the obvious with dozens of syntax elements which, *in
isolation*, it would be silly to care about. But syntax defines the feel
of the language. Perl and Java have better (or at least *larger*)
libraries, although arguably not as many "batteries included", but the
syntax, oh my. We use Python because it is Python and not Perl or Basic
or Fortran or Java. If the syntax changes, so does the language.
Yes, in isolation the question of != versus <> is a tiny little thing,
silly to drop Python merely because of it. But it's not silly to care
about the feel of the language. Python is as good as it is because Guido
cares very much indeed about the feel of the language, and so do many of
we Python users.
--
Steven
Aahz
<kwit...@telenet.be> wrote:
>
>I don't know if this is the right place to discuss the death of <> in
>Python 3.0, or if there have been any meaningful discussions posted
>before (hard to search google with '<>' keyword), but why would anyone
>prefer the comparison operator != over <>???
Are you asking why Python 3.0 gets rid of one of them or are you asking
why != was chosen over <>?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
hdante
> I don't know if this is the right place to discuss the death of <> in
> Python 3.0, or if there have been any meaningful discussions posted
> before (hard to search google with '<>' keyword), but why would anyone
> prefer the comparison operator != over <>???
>
> I've written an article about it to try and save this nice "is not
>
> Please set it straight in 3.0, and if not, convince me with a good
> reason of doing so, so that I can live with it and don't have to spend
> the rest of my life in 2.x ;).
I don't know, but we should have only one operator.
BTW, my opinion is that it's already time that programmer editors
have input methods advanced enough for generating this:
if x ≠ 0:
∀y ∈ s:
if y ≥ 0: f1(y)
else: f2(y)
;-)
Carl Banks
cybersource.com.au> wrote:
> On Sat, 29 Mar 2008 12:49:05 -0700, Carl Banks wrote:
> >> Please set it straight in 3.0, and if not, convince me with a good
> >> reason of doing so, so that I can live with it and don't have to spend
> >> the rest of my life in 2.x ;).
>
> > 1. It's not going to change in Python 3.0.
>
> > 2. It's a silly thing to care so much about that you will avoid using a
> > langauge because of it.
>
>
> But it's not silly to care
> about the feel of the language.
I'm not exactly sure who you're arguing with, bud. No one around here
that I can tell said anything about what you're railing against.
Carl Banks
Gabriel Genellina
> BTW, my opinion is that it's already time that programmer editors
> have input methods advanced enough for generating this:
>
> if x ≠ 0:
> ∀y ∈ s:
> if y ≥ 0: f1(y)
> else: f2(y)
Fine if you have the right keyboard... Try to write APL with a standard
keyboard :)
--
Gabriel Genellina
dewi...@gmail.com
cybersource.com.au> wrote:
> Given that <= is a comparison operator, not an assignment, why do you
> jump to the conclusion that != is an assignment? Why don't you argue that
> "x <= y" means "assign the value of x<y to x"?
Yes, you are right, that could be confusing ;).
> Since you jump to an invalid conclusion about !=, the rest of your
> argument fails.
No, you said <= could be confusing, but we're talking about <> here,
and there is no confusion about that :).
dewi...@gmail.com
> You're forcing your argument too much, both != and <> are NOT standard
> mathematics operators -- the standard not-equal operator is >< -- and
> I can assure you that both != and <> won't be comprehensible to non-
> programmers.
What I meant was that both < and > are standard mathematics operators,
and that by that knowledge one could deduce what <> means. But ><
would also be fine by me :).
dewi...@gmail.com
> MOST of Python's operators are based on C's. Consider, for example,
> the bitwise operators | ^ & << >> ~ and the compound assignment
> operators += -= etc.
>
> The exceptions are ** (from Fortran), //, and the logical operators.
Borrowing parts out of other languages (C in this case) is not a
problem, but I don't think there is a need to try be consistent with
C. It's Python, not C, so we should do things better ;).
Gabriel Genellina
Yes, there is: <> looks like "less or greater", and being equal or not is
a different thing that being less or greater. Trichotomy law holds for
real numbers (although some people don't even accept that) but not for
floating point (NANs); and Python isn't about numbers only. For a lot of
objects it makes sense to compare them for equality or not, but you can't
say which one is greater than the other (the weather forecast, books in a
bookstore)
--
Gabriel Genellina
Bjoern Schliessmann
> Ah yes, that is also used (I completely forgot about that one, my
> math's aren't that sharp anymore) and I think it's used more
> frequently than ><.
Where did you read that (I mean, which country)? I've never seen
this sign in any german or english book on
mathematics/physics/engineering I saw.
> but my argument was that no math book use != or <> (except in math
> for programmers).
That's true. Personally, I don't ever use "a!=b" in favor of "not
a==b".
Regards,
Björn
--
BOFH excuse #282:
High altitude condensation from U.S.A.F prototype aircraft has
contaminated the primary subnet mask. Turn off your computer for 9
days to avoid damaging it.
Steven D'Aprano
But you would be wrong, because "less than or greater than" is not the
same as "not equal to".
>>> 3+2j != 2-3j
True
>>> (3+2j < 2-3j) or (3+2j > 2-3j)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: no ordering relation is defined for complex numbers
--
Steven
Torsten Bronger
Bjoern Schliessmann writes:
> Lie wrote:
>
>> Ah yes, that is also used (I completely forgot about that one, my
>> math's aren't that sharp anymore) and I think it's used more
>> frequently than ><.
>
> Where did you read that (I mean, which country)? I've never seen
> this sign in any german or english book on
> mathematics/physics/engineering I saw.
Maybe he means "≷".
>> but my argument was that no math book use != or <> (except in
>> math for programmers).
>
> That's true. Personally, I don't ever use "a!=b" in favor of "not
> a==b".
As a side note, I've always found == rather ugly. I'd prefer to
have = for both purposes. The constructs that wouldn't work anymore
are rare as far as I can see (and possibly there are even
workarounds).
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bro...@jabber.org
(See http://ime.webhop.org for further contact info.)
Steven D'Aprano
> BTW, my opinion is that it's already time that programmer editors
> have input methods advanced enough for generating this:
>
> if x ≠ 0:
> ∀y ∈ s:
> if y ≥ 0: f1(y)
> else: f2(y)
>
> ;-)
Back in the 1990s, Apple's Hypercard accepted ≠ for "not equal". Of
course, Macs made it easy to type such special characters. By memory you
held down the Option key and typed an equals sign. For ≥ you used Option
and less-than. That worked in *any* Mac application.
Ah, glory days.
But I digress. In Python we can write the above as:
if x != 0:
[f1(y) if y >= 0 else f2(y) for y in s]
which for those not trained in algebra is probably more readable.
--
Steven
bearoph...@lycos.com
> it's already time that programmer editors
> have input methods advanced enough for generating this:
> if x ≠ 0:
> ∀y ∈ s:
> if y ≥ 0: f1(y)
> else: f2(y)
Take a look at Fortress language, by Sun. A free (slow) interpreter is
already available.
(Mathematica too allows you to write those symbols, but it costs a
lot, and (despite tons of good things it has) as *programming
language* it's awful, IHMO).
Steven D'Aprano:
> In Python we can write the above as:
> if x != 0:
> [f1(y) if y >= 0 else f2(y) for y in s]
Your code builds an actual array (Python list) of results, while I
think the original code just calls f1/f2.
Bye,
bearophile
hdante
wrote:
My sugestion considered using standard keyboards (hint: read again).
Bjoern Schliessmann
> BTW, my opinion is that it's already time that programmer editors
> have input methods advanced enough for generating this:
Could you please list some that do, and are also convenient?
Regards,
Björn
--
BOFH excuse #288:
Hard drive sleeping. Let it wake up on it's own...
Bjoern Schliessmann
> Maybe he means "?".
Haven't seen this either, nor do I think it's the same than "<>".
From afar, it looks more like "><". But this does more look like
South Park style shut eyes than an operator. :)
Regards,
Björn
--
BOFH excuse #407:
Route flapping at the NAP.
Torsten Bronger
Bjoern Schliessmann writes:
> hdante wrote:
>
>> BTW, my opinion is that it's already time that programmer editors
>> have input methods advanced enough for generating this:
>
> Could you please list some that do, and are also convenient?
Define "convenient". Emacs is generally not regarded as being
convenient, however, it has very strong input methods. I type
"\gtrless" and get "≷", or "\forall" and get "∀".
Colin J. Williams
> I don't know if this is the right place to discuss the death of <> in
> Python 3.0, or if there have been any meaningful discussions posted
> before (hard to search google with '<>' keyword), but why would anyone
> prefer the comparison operator != over <>???
>
> I've written an article about it to try and save this nice "is not
> equal" operator, located at http://dewitters.koonsolo.com/python_neq.html
>
> reason of doing so, so that I can live with it and don't have to spend
> the rest of my life in 2.x ;).
Algol 60 had no such operator.
Algol-W had (not)= [(not) was a negative
symbol, not on our current keyboard]
Simula 67 introduced <>
Pascal uses <> [Pascal is still
available - http://www.freepascal.org/]
C uses !=
[http://cermics.enpc.fr/~ts/C/CONCEPT/expressions.html#rel]
I prefer <> but I feel that it's better
not to have two ways of representing
not equal.
The powers that be have chosen !=. I
accept this on the grounds that current
languages seem to have nade that choice.
Colin W.
MRAB
wrote:
standard APL symbols with keywords.
Dan Bishop
wrote:
> Hallöchen!
>
> Bjoern Schliessmann writes:
> > Lie wrote:
>
> >> Ah yes, that is also used (I completely forgot about that one, my
> >> math's aren't that sharp anymore) and I think it's used more
> >> frequently than ><.
>
> > Where did you read that (I mean, which country)? I've never seen
> > this sign in any german or english book on
> > mathematics/physics/engineering I saw.
>
> Maybe he means "≷".
>
> >> but my argument was that no math book use != or <> (except in
> >> math for programmers).
>
> > That's true. Personally, I don't ever use "a!=b" in favor of "not
> > a==b".
>
> As a side note, I've always found == rather ugly. I'd prefer to
> have = for both purposes.
The earliest versions of Python *did* use = for both purposes.
> The constructs that wouldn't work anymore
> are rare as far as I can see (and possibly there are even
> workarounds).
The construct a = b == c could be rewritten as a = (b = c).
Lie
mail-0306.20.chr0n...@spamgourmet.com> wrote:
> Torsten Bronger wrote:
> > Maybe he means "?".
>
> Haven't seen this either, nor do I think it's the same than "<>".
> From afar, it looks more like "><".
Actually I meant an X-like symbol that is made not by crossing but by
><. I retracted saying it is the standard, now that I think about it
the last time I saw >< was in elementary school (although it stuck on
my head better than a crossed =, which I first met in high school).
> But this does more look like
> South Park style shut eyes than an operator. :)
lol, I agree, it looks too much like closed eye smiley. Forums might
automatically convert them to graphic smileys so it is obviously a bad
choice if it is to be used.
Lie
mail-0306.20.chr0n...@spamgourmet.com> wrote:
> Lie wrote:
> > Ah yes, that is also used (I completely forgot about that one, my
> > math's aren't that sharp anymore) and I think it's used more
> > frequently than ><.
>
> Where did you read that (I mean, which country)? I've never seen
> this sign in any german or english book on
> mathematics/physics/engineering I saw.
It was in my elementary school at Indonesia (FYI, it is also used as
antonym sign in languages (at least in my country)). And I think I'll
retract that claim, >< wasn't the standard, a crossed = is the
standard (btw, with a little imagination != looks like a crossed =).
Lie
(snip)
> BTW, my opinion is that it's already time that programmer editors
> have input methods advanced enough for generating this:
>
> if x ≠ 0:
> ∀y ∈ s:
> if y ≥ 0: f1(y)
> else: f2(y)
That would be a nightmare.
Programming language (or most computer-based texts) should only use
basic ASCII characters, except if it can't be helped since typing non-
ASCII characters is still unreliable. It'd also be a headache to
memorize what keyboard combinations to use to type a character. Not to
mention how much more complex would the keyboard design be. Also not
mentioning how much more complex the language design would be to
handle all those non-ASCII characters.
Gabriel Genellina
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.
--
Gabriel Genellina
Dan Bishop
> On Mar 29, 5:55 pm, kwitt...@telenet.be wrote:
>
> > I don't know if this is the right place to discuss the death of <> in
> > Python 3.0, or if there have been any meaningful discussions posted
> > before (hard to search google with '<>' keyword), but why would anyone
> > prefer the comparison operator != over <>???
>
>
> You're forcing your argument too much, both != and <> are NOT standard
> mathematics operators -- the standard not-equal operator is >< -- and
> I can assure you that both != and <> won't be comprehensible to non-
> programmers.
A lot of non-programmers use Microsoft Excel, which uses <> for the
Not Equal operator.
FWIW, the non-programmers on one forum I post on tend to use =/= .
hdante
mail-0306.20.chr0n...@spamgourmet.com> wrote:
> hdante wrote:
> > BTW, my opinion is that it's already time that programmer editors
> > have input methods advanced enough for generating this:
>
> Could you please list some that do, and are also convenient?
AFAICT there's none. This should be easy to implement on emacs, or in
SCIM.
Torsten Bronger
hdante writes:
> On Mar 30, 9:45 am, Bjoern Schliessmann <usenet-
> mail-0306.20.chr0n...@spamgourmet.com> wrote:
>
>> hdante wrote:
>>
>>> BTW, my opinion is that it's already time that programmer
>>> editors have input methods advanced enough for generating this:
>>
>> Could you please list some that do, and are also convenient?
>
> AFAICT there's none. This should be easy to implement on emacs,
It *is* implemented in Emacs. You can even choose from many input
methods, optimised for differend areas/languages.
hdante
> On Mar 30, 12:11 pm, hdante <hda...@gmail.com> wrote:
> (snip)
>
> > BTW, my opinion is that it's already time that programmer editors
> > have input methods advanced enough for generating this:
>
> > if x ≠ 0:
> > ∀y ∈ s:
> > if y ≥ 0: f1(y)
> > else: f2(y)
>
> That would be a nightmare.
>
> Programming language (or most computer-based texts) should only use
> basic ASCII characters, except if it can't be helped since typing non-
I completely disagree. Unicode should be used whenever the
architecture doesn't have memory restrictions. For general
(plain-)text there's no sense in talking about ASCII. The only
language that "fits" in it that I can remember is Latin.
> ASCII characters is still unreliable. It'd also be a headache to
> memorize what keyboard combinations to use to type a character. Not to
You'd have to memorize, for example "!=" and ">=".
> mention how much more complex would the keyboard design be. Also not
The keyboard would be the same.
> mentioning how much more complex the language design would be to
> handle all those non-ASCII characters.
Wrong.
hdante
wrote:
> Hallöchen!
>
> hdante writes:
> > On Mar 30, 9:45 am, Bjoern Schliessmann <usenet-
> > mail-0306.20.chr0n...@spamgourmet.com> wrote:
>
> >> hdante wrote:
>
> >>> BTW, my opinion is that it's already time that programmer
> >>> editors have input methods advanced enough for generating this:
>
> >> Could you please list some that do, and are also convenient?
>
> > AFAICT there's none. This should be easy to implement on emacs,
>
> 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.
>
> Tschö,
> Torsten.
>
> --
> Torsten Bronger, aquisgrana, europa vetus
> Jabber ID: bron...@jabber.org
> (Seehttp://ime.webhop.orgfor further contact info.)
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
--
BOFH excuse #123:
user to computer ratio too high.
Torsten Bronger
Bjoern Schliessmann writes:
> Torsten Bronger wrote:
>
>> Emacs is generally not regarded as being convenient, however, it
>> has very strong input methods. I type "\gtrless" and get "?", or
>> "\forall" and get "?".
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.
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
--
BOFH excuse #154:
You can tune a file system, but you can't tune a fish (from most
tunefs man pages)
Terry Reedy
"Bjoern Schliessmann" <usenet-mail-03...@spamgourmet.com> wrote
in message news:65c0bfF...@mid.individual.net...
| > 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
escribió:
> "Bjoern Schliessmann" <usenet-mail-03...@spamgourmet.com>
> wrote
> in message news:65c0bfF...@mid.individual.net...
> | > 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.
>
> 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
Jorge Vargas
<gags...@yahoo.com.ar> wrote:
> En Mon, 31 Mar 2008 16:17:39 -0300, Terry Reedy <tjr...@udel.edu>
> escribió:
>
>
> > "Bjoern Schliessmann" <usenet-mail-03...@spamgourmet.com>
> > wrote
> > in message news:65c0bfF...@mid.individual.net...
> > | > 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.
> >
> > 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.
>
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.
Torsten Bronger
Jorge Vargas writes:
> On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina
> <gags...@yahoo.com.ar> wrote:
>
>> [...]
>>
>> 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.
Ben Finney
> 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.
Want <URL:http://www.cafepress.com/nucleartacos.26721820>.
--
\ "bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
`\ rm * halt LART LART LART!" -- The Swedish BOFH, |
_o__) alt.sysadmin.recovery |
Ben Finney
Gabriel Genellina
escribió:
> 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:
>>> año = 2008
>>> print("halagüeño")
halagüeño
>>> print("halagüeño".encode("latin1"))
b'halag\xfce\xf1o'
--
Gabriel Genellina
Konstantin Veretennicov
En Tue, 01 Apr 2008 04:15:57 -0300, Jorge Vargas <jorge....@gmail.com>
escribió:
Python 3 is a good step in that direction. Strings are unicode,
> 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.
identifiers are not restricted to ASCII, and the default source encoding
is not ASCII anymore (but I don't remember which one).
Steve Holden
> Hallöchen!
>
> Jorge Vargas writes:
>
>> On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina
>> <gags...@yahoo.com.ar> wrote:
>>
>>> [...]
>>>
>>> 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.
>
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steve Holden
> Hallöchen!
>
> Jorge Vargas writes:
>
>> On Tue, Apr 1, 2008 at 6:03 AM, Gabriel Genellina
>> <gags...@yahoo.com.ar> wrote:
>>
>>> [...]
>>>
>>> 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.
>
John J. Lee
[...]
>> There was a version of APL for the Sinclair QL which replaced the
>> standard APL symbols with keywords.
>
> 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
wrote:
> En Sun, 30 Mar 2008 11:10:20 -0300, MRAB <goo...@mrabarnett.plus.com>
> escribió:
>
>
>
> > On Mar 30, 6:35 am, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> > wrote:
> >> En Sun, 30 Mar 2008 02:11:33 -0300, hdante <hda...@gmail.com> escribió:
>
> >> > BTW, my opinion is that it's already time that programmer editors
> >> > have input methods advanced enough for generating this:
>
> >> > if x ≠ 0:
> >> > ∀y ∈ s:
> >> > if y ≥ 0: f1(y)
> >> > else: f2(y)
>
> >> Fine if you have the right keyboard... Try to write APL with a standard
> >> keyboard :)
>
> > There was a version of APL for the Sinclair QL which replaced the
> > standard APL symbols with keywords.
>
> 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.
>
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... :-)
Hendrik van Rooyen
>How did programmers manage back then in 32k?
Some of the answers, in no particular sequence, are:
Tight, small operating systems that did the minimum.
Assembler.
Sequential Processing:
- small tasks with multiple passes on tape
( like the concept of Unix pipes )
Overlays.
Character based menu systems.
No OO.
Code structured to the point of incomprehensibility:
- if ten or so instructions looked similar,
you forced calls instead of inlining.
Procedural languages, close to the metal.
Small, fixed length, fixed type character based data structures.
Some of the other veterans may want to add to this list.
- Hendrik
Bob Martin
>John J. Lee wrote:
>
>>How did programmers manage back then in 32k?
>
>Some of the answers, in no particular sequence, are:
>
>Tight, small operating systems that did the minimum.
Apart from the GUI stuff, mainframe operating systems did everything that
today's x86 OSs do. Early releases of IBM's OS/360 could run in 64KB
and offered Fortran, Cobol etc
The task time-sharing on release 12 (MVT, about 1971) was better than
that in Windows XP or Vista (that should start a few arguments).
>Assembler.
>Sequential Processing:
>- small tasks with multiple passes on tape
>( like the concept of Unix pipes )
>Overlays.
>Character based menu systems.
>No OO.
>Code structured to the point of incomprehensibility:
>- if ten or so instructions looked similar,
>you forced calls instead of inlining.
I think you have that back-to-front - it is unstructured code with lots
of inlining which is incomprehensible.
Paul Rubin
> Some of the other veterans may want to add to this list.
Overlays, lots and lots of them, in multiple levels intricately
arranged.
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.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
D'Arcy J.M. Cain
Tim Roberts <ti...@probo.com> wrote:
> 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?
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.