dictionary/hash and '1' versus 1

[Reedick, Andrew]

> -----Original Message-----
> From: python-list-bounces+jr9445=att.com at python.org [mailto:python-
> list-bounces+jr9445=att.com at python.org] On Behalf Of Paddy
> Sent: Monday, January 07, 2008 12:52 PM
> To: python-list at python.org
> 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