<> and DeprecationWarn ing

[Gerrit Holl]

Hi,

the <> inequality test operator has been deprecated for a loooooong time.

Is there a reason that it doesn't trigger a DeprecationWarn ing?

$ python2.2 -Wall -c "print 0 <> 0"
0
$ python2.3 -Wall -c "print 0 <> 0"
False

Or is the only reason that is has never been implemented?
IANACS, but this doesn't seem very complicated to implement to me...

yours,
Gerrit.

--
196. If a man put out the eye of another man, his eye shall be put out.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Kom in verzet tegen dit kabinet:
http://www.sp.nl/

[Skip Montanaro]

Gerrit> Is there a difference between obsolescent, obsolete and
Gerrit> deprecated?

Yes, but it's sort of like the Eskimos ("arctic native americans"?) having
several different words for "snow". The subtle differences are lost on
people who've never seen snow. ;-)

Dictionary.com (via Google) shows these relevant (and related) definitions:

obsolescent - Being in the process of passing out of use or usefulness;
becoming obsolete. (Also, in a biological sense "gradually
disappearing".

obsolete - No longer in use or outmoded in design, style, or
construction (two definitions).

deprecate - To express disapproval of; deplore, or to belittle;
depreciate.

Of these, deprecate's computer meaning seems to be quite far from it's
using in non-computer English. Further down the page, it shows a couple
more-to-our-needs definitions of deprecate:

Said of a program or feature that is considered obsolescent and in the
process of being phased out, usually in favour of a specified
replacement. Deprecated features can, unfortunately, linger on for many
years. This term appears with distressing frequency in standards
documents when the committees writing the documents realise that large
amounts of extant (and presumably happily working) code depend on the
feature(s) that have passed out of favour. (from The Free On-line
Dictionary of Computing)

Said of a program or feature that is considered obsolescent and in the
process of being phased out, usually in favor of a specified
replacement. Deprecated features can, unfortunately, linger on for many
years. This term appears with distressing frequency in standards
documents when the committees writing the documents realize that large
amounts of extant (and presumably happily working) code depend on the
feature(s) that have passed out of favor. (from the Jargon File)

In the context of discussions about '<>', I think "obsolecent " and
"deprecated " mean roughly the same thing, though "deprecated " suggests a
more formal notion. In Python, if a language feature is deprecated, there
is generally a specified sunset period. As Barry suggests, even though '<>'
is obsolescent, it's likely to be around for a long while.

One might speculate that as 3.0 nears, the last release or two in the 2.x
line might provide a way for programmers to run their code with a __future__
import something like

from __future__ import deprecated_in_3

or if the effect is desired more globally, to specify a --three or -3 flag
on the interpreter command line.

Skip

[Richard Brodie]

"Skip Montanaro" <sk**@pobox.com > wrote in message
news:ma******** *************** **************@ python.org...

In the context of discussions about '<>', I think "obsolecent " and
"deprecated " mean roughly the same thing, though "deprecated " suggests a
more formal notion. In Python, if a language feature is deprecated, there
is generally a specified sunset period. As Barry suggests, even though '<>'
is obsolescent, it's likely to be around for a long while.

In Fortran, it's the other way round. Heinous constructs like computed
GOTOs are obsolesecent in Fortran 90 and removed in Fortran 95,
whilst COMMON blocks are merely deprecated.

As you suggest, the subtle distinctions that may exist probably have to give
way to locally accepted usage.

[Barry Warsaw]

On Mon, 2003-10-20 at 13:59, Erik Max Francis wrote:

Now comes the argument over whether _obsolescent_ and _deprecated_ are
synonymous in this context :-).

Technically, I'd say they aren't because <> constructs don't generate
deprecation warnings.

-Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUAP5Qve3E jvBPtnXfVAQKqqQ P9F8Cssp43inCQT 5SG8FKKjBrZQ6ko dJZX
D0MTBEtFR/BMnXo5ZRSaTgd16 jwKc8c60ZNC48WT Iij9pmQB0Qvi/JSHwIrJcI1r
wjfh/B3O6BQXHtiqtJty Mhgt5kdYtJgDo5U KE2TOHjppu3/5zPSmtfDROm6nEL BG
wyAtPIi2EsE=
=LwG0
-----END PGP SIGNATURE-----

[Lulu of the Lotus-Eaters]

Barry Warsaw <ba***@python.o rg> wrote previously:
|I'm confident there's no way <> can be officially deprecated

Heck, we true believers should be more ambitious: Deprecate the
heretical '!=' pseudo-assignment!

[Alex Martelli]

Barry Warsaw wrote:

On Mon, 2003-10-20 at 13:59, Erik Max Francis wrote:

Now comes the argument over whether _obsolescent_ and _deprecated_ are
synonymous in this context :-).

Technically, I'd say they aren't because <> constructs don't generate
deprecation warnings.

So let's introduce obsolescence warnings...!-)
Alex

[Erik Max Francis]

Barry Warsaw wrote:

Technically, I'd say they aren't because <> constructs don't generate
deprecation warnings.

I was being semifacetious. In my experience, usually they are used in
different ways. Deprecation is a stricter form of obsolescence.
Obsolescent just means that the feature should no longer be used, since
it has been replaced by superior forms. Deprecated means that an
obsolescent form has actually been marked for future removal. A
deprecated feature can be removed, an obsolescent feature can become
deprecated.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ If you're not besides me / I'll do your best / To carry on
\__/ India Arie

[Barry Warsaw]

On Mon, 2003-10-20 at 14:45, Lulu of the Lotus-Eaters wrote:

Barry Warsaw <ba***@python.o rg> wrote previously:
|I'm confident there's no way <> can be officially deprecated

Heck, we true believers should be more ambitious: Deprecate the
heretical '!=' pseudo-assignment!

Now there's a bold and enlightened Pythoneer! Three cheers!

-Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUAP5Q6BnE jvBPtnXfVAQIW3Q P/YfcIce7L8JJ/oWwjbY49wTjUHd2 j6lGm
zTwhC3rUs7ISpCk Ztt0O0Yj+vOTPmL IgAZopbRu/VGxJo5JMOmigWxx I+f9PEliI
H0Hs/Ly9GDcXntyF71w9 rAHK0oOiSgCZttd HeybADcPx/x0bTw+kOD1Q96rh RejT
EXAAk/uAg3Y=
=9DHp
-----END PGP SIGNATURE-----

[Barry Warsaw]

On Mon, 2003-10-20 at 15:09, Alex Martelli wrote:

Barry Warsaw wrote:

On Mon, 2003-10-20 at 13:59, Erik Max Francis wrote:

Now comes the argument over whether _obsolescent_ and _deprecated_ are
synonymous in this context :-).

Technically, I'd say they aren't because <> constructs don't generate
deprecation warnings.

So let's introduce obsolescence warnings...!-)

class
SilentPendingMi sguidedObsolesc enceSuggestion( PendingDeprecat ionWarning):
pass

:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iQCVAwUAP5Q6X3E jvBPtnXfVAQJ9mA P/f51+7+eVX3gKDWV ifqI3sDM4MNv8Y3 45
Tk0kvPsqKEYpM60 U2DrkVmpVCinkuE QnP+9nBbNye7M/30VRt8VGqbBpNjd NCvSu
mJPjt51kjd4cQae jSHY7/3Kr0Fn8SXHVXvKR cXegadX27ZuFQj2 sonsIuRtfWnTm
yk36wyRta4M=
=KW/x
-----END PGP SIGNATURE-----

[Wojtek Walczak]

Dnia Mon, 20 Oct 2003 11:44:17 -0400, Barry Warsaw napisa³(a):

> the <> inequality test operator has been deprecated for a loooooong tim=

e.

Who said that?

Well, Guido doesn't like it, but Just does, so that cancels out the Van
Rossum vote <wink>. I'm on Just's side though, but this is about as
religious an argument as Pythoneers get. I'm confident there's no way
<> can be officially deprecated as long as Python 2.x is alive.

Is there any outline to mark it as deprecated in docs and the code
somewhere between 2.x and 3.0? I know that this is _distant future_,
but we can think about it and maybe vote. I'm on Guido's side not
because I don't like it, but because I think that Python doesn't need
two 'not equal' operators. It reminds me about ruby and its methods
for built-in classes which are doubled in some cases. This is nothing more
than a pollution.
--
[ Wojtek Walczak - gminick (at) underground.org .pl ]
[ <http://gminick.linuxse curity.pl/> ]
[ "...rozmait e zwroty, matowe od patyny dawnosci." ]

[Dennis Lee Bieber]

Skip Montanaro fed this fish to the penguins on Monday 20 October 2003
10:08 am:

Yes, but it's sort of like the Eskimos ("arctic native americans"?)
{Continuing the previous response -- I don't know of any way to
retrieve for editing a message that has been "sent" from KNode; unlike
Agent's outbox}

I think my dislike for != is that Python /does/ have a NOT keyword,
unlike C, where the ! alone is "not".

So I guess that I'm saying I'd have preferred to see

x not == y
(though this is where folks complaining about == vs = get the advantage)
vs
x != y

Though I feel comfortable with

x <> y
(it's faster to type, among other things -- left-shift, rock the right
hand over the ., keys -- vs right-shift, 1, move from right-shift to =)

-- =============== =============== =============== =============== == <
wl*****@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
=============== =============== =============== =============== == <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <