dictionary/hash and '1' versus 1

[Paddy]

On Jan 7, 7:26 pm, "Reedick, Andrew" <jr9... at ATT.COM> wrote:
> > -----Original Message-----
> > From: python-list-bounces+jr9445=att.... at python.org [mailto:python-
> > list-bounces+jr9445=att.... at python.org] On Behalf Of Paddy
> > Sent: Monday, January 07, 2008 12:52 PM
> > To: python-l... 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.
>

I guess it comes down to the differences in fundamental principles of
Perl and Python. Perl is developed to "Do what I mean", whereas Python
would be more like "Do as I say". Perl strives to be more like a
spoken language, Python strives to have a core set of powerful &
composable ideas.

On your specific example I'd guess that both schemes work well its
just that I am more comfortable with Pythons one set of more
overloaded operators and vice-versa for yourself, leading us both to
have problems when we switch between Perl and Python :-)

- Paddy.