RE: dictionary/hash and '1' versus 1

-----Original Message-----
From: python-list-bounces+jr9445=att.com@xxxxxxxxxx [mailto:python-
list-bounces+jr9445=att.com@xxxxxxxxxx] On Behalf Of Paddy
Sent: Monday, January 07, 2008 12:52 PM
To: python-list@xxxxxxxxxx
Subject: Re: dictionary/hash and '1' versus 1

Or how using different operators for similar operations on different
types causes confusion.
i.e. == versus eq; > versus gt
If Perl had, for example, a complex number 'base' type would that need
yet another set of operators?

The real question is: what's the simplest way to implement complex
numbers without sacrificing understanding, accuracy, and convenience? I
would say, no new operators. Imaginary numbers are numbers and should
use numeric operations which means overloaded match operators.

As background: In order to keep things simple, Perl's string operators
are string-like. Math operators are math.
'2' * 5 = 10
'2' x 5 = '22222' ('x' is a char, so think strings)
==, >, >=, <, <=
eq, gt, ge, lt, le (string abbreviations for equal, greater
than, etc.)
'1' + 1 = 2
'1' . 1 = 11 (Think period at the end of a sentence, which
implies stringing strings together.)


Well enough Perl vs Python. The thing is, that when writing in another
programming language you have to use its idioms or you end up fighting
the language in attempt to make it work like another language you are
more familiar with. In Python strings won't ever automatically change
to numbers.

Agreed. However looking towards the future (new versions of
Perl/Python, new languages, new paradigms) is it worth asking whether
it's better/clearer/easier/more_accurate to
a) type cast the data: a + b (a and b must be of the same type)

a.1) explicitly type cast the data: str(a) + str(b)
(if a and b are different types)
b) type cast by operator: '1' + 1 = 2; '1' . 1 = '11'
c) go really old school with: concat('1', 1); add('1', 1)

IMO, since Python is strongly but dynamically typed, a) is the 'worst'
solution. If you forget to type cast, you're boned, since you probably
won't find the problem until the code block is actually executed and an
exception is thrown. You could defensively type cast everything, but
that can clutter the code, and cluttered code is harder to understand
and keep bug free. With b) or c), the compiler will type cast as you
intended. Again, just my opinion.

Anyway, it's little things like '1' + 1 that will probably prevent
programming syntax from ever being similar to naturally spoken language.


*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621


.

Relevant Pages

  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)
  • Re: syntax...
    ... B&D on the part of the language designer. ... probably handle concatenation of string literals by itself, ... bitwise XOR, or if not that, then exponentiation.) ...
    (comp.lang.misc)
  • Why C Is Not My Favourite Programming Language
    ... C has no string type. ... compiler take care of the rest. ... Why does any normal language ... the programmer fail. ...
    (comp.lang.c)
  • Re: Controlling Javascript from server side
    ... but five different language implementations here. ... 'true' means that the request must be handled asynchronously. ... There is exactly *no* reason for such a thing here. ... | percent-endoded string). ...
    (comp.lang.javascript)
  • Re: Theodore Adorno, a prophet of data systems design
    ... C may not be a forgiving language, ... >> attention get burned with the memory leaks, and buffer overruns, ... by a small, compact team of brilliant programmers, or it may be ... so you agree that it is not a limit on the length of the string, ...
    (comp.programming)