Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Numbers and truth values

Reply
Thread Tools

Numbers and truth values

 
 
Mel Wilson
Guest
Posts: n/a
 
      04-28-2007
John Nagle wrote:
> "True", "False", and "None" should be reserved words in Python.
> "None" already is.


The permissiveness makes it less painful to upgrade to new versions of
Python. True and False only recently got assigned conventional
values, but you can still import old modules without worrying whether
they might violate the new rule; if True and False once meant
something special to them, it will still mean the same thing.

Meanwhile new code can follow the new conventions.



Mel.

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-29-2007
On Sat, 28 Apr 2007 11:35:36 -0700, John Nagle wrote:

>> Python forbids very few things in comparison to other languages. The
>> attitude is "We're all adults here". Because Python is such a dynamic
>> language, it is often hard for the compiler to tell the difference between
>> something you are doing deliberately and a mistake.

>
> I'd have to consider that a bug.


[snip]

> "True", "False", and "None" should be reserved words in Python.
> "None" already is.


What are you going to do about the code that pre-dates the introduction of
bools that defines

False = 0
True = not False

at the start of the module? The Python philosophy is to break existing
code as little as possible (at least until Python 3).



--
Steven

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-29-2007
On Sat, 28 Apr 2007 23:54:01 +0200, Szabolcs wrote:

> But I still think that it is an inconsistency to allow to redefine a
> _value_ like True or False (not a built-in function that may have been
> missing in earlier versions). Saying True = 2 is just like saying 3 = 2.


Well, it might seem that way, but it isn't really. It's more like having
built-in names

One = 1
Zero = 0

(plus some special code so that when you say "print One" it prints
"One" rather than 1) in Python. You wouldn't be surprised to be able to
redefine One = 2 there, would you?

The ability to shadow built-ins is a fact of life in the Python world.
Python has a lot of built-ins, and very few keywords, and that situation
is unlikely to change. As Alex explained, the philosophy is not to slow
the compiler and interpreter down with checks against those sort of
problems directly, but to trust the programmer to call external tools like
pylint and pychecker if they want. It may be that True and False will
(like None before it) be moved from the built-ins category into the
keyword category, but I don't think that's the most pressing problem in
Python.



--
Steven.

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      04-29-2007
Szabolcs <(E-Mail Removed)> wrote:

> But I still think that it is an inconsistency to allow to redefine a
> _value_ like True or False (not a built-in function that may have been
> missing in earlier versions). Saying True = 2 is just like saying 3 = 2.


True and False were *ALSO* missing in earlier versions of Python (2.2.1
and back -- they were introduced in 2.2.2, smack in the middle of a
minor release cycle, a release engineering error which Guido has vowed
never to repeat).

There's a lot of code around that starts with

False = 0
True = not False

(or similar), so it can run just as well on (e.g) 2.2.1 (and earlier) as
2.2.2 (and later) -- breaking all of that code which always worked fine
is a decision not to be taken as lightly as you appear to imply.


Alex
 
Reply With Quote
 
Beliavsky
Guest
Posts: n/a
 
      04-29-2007
On Apr 28, 4:05 pm, (E-Mail Removed) (Alex Martelli) wrote:
> John Nagle <(E-Mail Removed)> wrote:
>
> > I'd have to consider that a bug.

>
> > Some very early FORTRAN compilers allowed you to redefine
> > integer constants:

>
> > CALL SET(25,99)
> > WRITE (6,100) 25
> > 100 FORMAT(I6)

>
> > SUBROUTINE SET(IVAR, INEWVAL)
> > IVAR = INEWVAL

>
> > would print

>
> > 99

>
> > It was generally agreed by 1970 or so that this was a bad idea,
> > and was taken out of the language.

>
> It was still perfectly legal in the Fortran 1977 standard for a compiler
> to cause this effect, because the Fortran source you quote has
> *undefined behavior* -- the compiler doesn't have to diagnose this error
> and can cause any effects as a consequence.
>
> The point of Fortran is to let the compiler generate the fastest code it
> can, NOT to "tenderly hold your hand" lest scary bugs disturb your
> blessed and dreamy innocence.


The point of Fortran has been to make scientific programmers more
productive, and catching errors and producing fast programs are BOTH
ways of doing that. Compilers are judged on BOTH criteria:
speed: http://www.polyhedron.com/pb05/linux/f90bench_p4.html
diagnostics: http://www.polyhedron.com/pb05/linux/diagnose.html

If there is a compiler with great compile- and run-time debugging
capability with the right options turned on, and if the compiler also
produces optimally fast code with another set of options (or if
another compiler does this), isn't that the best of both worlds?

> If this has changed in the Fortran 1990 standard or later, then I can
> only say I'm happy I stopped using Fortran heavily before such standards
> became widespread in commonly available compilers -- by the late '90s,
> when I was still using _some_Fortran, it was Fortran '77, as that was
> the version that was widely available and well optimized.


I don't think the official status of such has changed -- it's still
illegal to change a constant and the compiler is still not required to
catch the error -- but compilers may be more likely to reject
such code as before, helping programmers spot errors. IMO that's a
good thing.

When is no longer using a language, one has the luxury of thinking
about it in an ideological rather than practical manner.

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      04-30-2007
Beliavsky <(E-Mail Removed)> wrote:
...
> > If this has changed in the Fortran 1990 standard or later, then I can
> > only say I'm happy I stopped using Fortran heavily before such standards
> > became widespread in commonly available compilers -- by the late '90s,
> > when I was still using _some_Fortran, it was Fortran '77, as that was
> > the version that was widely available and well optimized.

>
> I don't think the official status of such has changed -- it's still
> illegal to change a constant and the compiler is still not required to
> catch the error


Oh good -- I'm happy to hear that the original spirit IS still around.

> -- but compilers may be more likely to reject
> such code as before, helping programmers spot errors. IMO that's a
> good thing.


In general, as an engineer, I think that making tools more complicated
so that a single tool can serve multiple purposes is not necessarily a
win. I do not want one pair of shoes that are designed to be excellent
for running AND for dancing AND for mountain hiking: I'd much rather
have three specialized pairs of shoes instead, one pair for running, one
for dancing, one for hiking.

Similarly, I'd rather have one tool to take presumably-correct sources
and generate great machine code from them, and separate tools to nitpick
the bejeezus out of the sources to make really sure they ARE indeed
perfectly correct from all viewpoints. Two (or more) simple, fully
specialized tools make for a better toolbox than one complex,
multi-purpose one. Few except engineers seem to understand this.

> When is no longer using a language, one has the luxury of thinking
> about it in an ideological rather than practical manner.


I thought about Fortran in exactly the same way when I was doing most of
my coding in it, and also using it to teach "numerical computing" in
university. Most errors came (and still come) from people who just
don't understand the underlying mathematical nature and realities of
floating point (and numerical computations more generally), and I never
expected a compiler to magically start warning the user about "you're
using a very badly conditioned algorithm for this computation", the
one thing that would have really saved me a lot of time in my advisory
and teaching roles. Exactly the same problems keep surfacing in
programs in Python and any other language too, barely veiled by today's
growing propensity for double-precision and wider-yet floats; offering a
rich library of functions is NOT a viable replacement for understanding
and approaching computation correctly (users will just call extremely
general library functions, rather than understand their problem's
specific "geometries" and address them appropriately).

(Let me offer one more plug for my favorite "book about programming
without a single line of code in it", Foreman Acton's "Real computing
made real", now out in a wonderfully cheap Dover edition: Acton makes
this case better than I've ever seen it made elsewhere, and offers many
excellent examples of how numerical computation SHOULD be done).


Alex
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fibonacci Numbers and Lucas Numbers Andrew Tatum C++ 6 05-27-2007 12:47 AM
DVD Verdict reviews: WHERE THE TRUTH LIES, YOURS, MINE AND OURS (2005), and more! DVD Verdict DVD Video 0 02-28-2006 10:08 AM
Re: Numbers and more numbers... Linda A+ Certification 1 12-03-2005 12:43 AM
Re: Numbers and more numbers... Breedo A+ Certification 0 12-02-2005 12:45 AM
A70 and CF X and USB speed - here the TRUTH!!! srcbr Digital Photography 7 01-30-2004 03:27 AM



Advertisments