Sorting distionary by value

[Jeff Shannon]

In article <slrnaa96gr.gif.philh at comuno.freeserve.co.uk>, 
philh at comuno.freeserve.co.uk says...
> Jeff Shannon <jeff at ccvcorp.com> wrote:
> >
> >I disagree with your conception of high level language.  A 
> >high level language hides
> >unnecessary details, but I don't think that conversion between 
> >different data types
> >is an unnecessary detail.  
> 
> So would you prefer:
> 
>    float(2) + 3.14
> 
> to:
> 
>    2 + 3.14
> 
> ?

In the particular case of numbers, it does make practical sense 
to consider "Number" to be a single data type, with several 
specializations (integer, float, complex).  Thus, one can 
(somewhat) reasonably claim that converting int-->float is not 
truly between different data types.  (Judging from the 
discussions regarding new division, this seems to be the view 
that Guido takes.)  But I do consider numerics to be a special 
case, and not a good indication of a general rule.

However, None is not a number, nor is it a sequence of any sort, 
nor is it... well, anything.  None is a specific "not valid" 
value, and making it valid to perform arithmetic on a non-valid 
value is confusing at best.

> >High level means that a logical step can be done in one
> >or two lines of code,
> 
> Define "logical step".

Define "semantic".  What I mean by this is that a low-level 
language is one in which a single conceptual (semantic) step is 
broken down into a series of instructions.  A high-level language 
is one in which each conceptual step is done with a minimal 
number of instructions.  The specific definition of "a single 
conceptual step" is variable, and describes just *how* "high-
level" the language is.  (Compared to assembly, C is relatively 
high-level.)

> >There's a large class of cases where the interpreter, in 
> >trying to "do the right
> >thing", is as likely to guess wrongly as it is to guess right.
> 
> This is only true if what the interpreter will do is not cleanly 
> defined for the programmer.

No, it's also true if the behavior is non-intuitive, despite 
being well-defined.  Having a non-value be a valid component of 
an arithmetic expression is confusing.  (Should we also be able 
to perform arithmetic on floating-point NaNs?)  Confusing 
language constructs result in wrong programs, even when it's 
possible to examine closely and define exactly how it *should* 
behave.

> >  If you want an
> >interpreter that guesses anyhow, use Perl.
> 
> Yuck.
 
My point exactly.  What you're proposing would be a large step in 
the direction of Perl, and the fact that Python *doesn't* behave 
that way is exactly the reason that so many of us *prefer* Python 
over Perl.

-- 

Jeff Shannon
Technician/Programmer
Credit International