On Jan 7, 7:26 pm, "Reedick, Andrew" <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:python- > > [EMAIL PROTECTED] On Behalf Of Paddy > > Sent: Monday, January 07, 2008 12:52 PM > > To: [EMAIL PROTECTED] > > 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. -- http://mail.python.org/mailman/listinfo/python-list
