Why not FP for Money?

[Andrew Dalke]

Carlos Ribeiro wrote:
> I don't have enough knowledge of RE's theory, and I don't know if it
> can be generalized, but it's a great solution. Was it ever discussed
> here at c.l.py?

If "it" means "special lexical support for making regular expression
objects" then yes, and rejected.

If "it" means "the ability to manipulate regular expression parse
trees" then yes, to some extent.  Use the (undocumented internal)
module sre_parse.py to make a ... I think the right term is
"concrete data type".  Traversing that to make an abstract data
structure is easy, and what I did for my Martel system.

> Well, that's was the greatest part of your post. That you've got
> yourself into the hassle of checking a discussion nearly ten years old
> was fantastic, and the quality of the information you've recovered is
> nothing short of magnificent. Really. So much of superlatives :-)

Umm, thank Google for most of that.  For my part all I
remembered was that a conversation occured, that the addition
was very simple, and that the community voted for 'j' over 'i'.

> Looking back at that discussion, I think that we're on the right road.
> We already have a library working, and the proposed changes to the
> syntax follow the same precedent of the i(maginary) suffix. It's too
> early to tell, but the precendents looks good for the 'd'-suffix
> proposal.

I suspect you're right.  I'm just getting reactionary
in my old age.  :)

> There is an important difference in favor of complex numbers. I think
> that the support for the notation of complex numbers is more important
> for OUTPUT than for INPUT. It's much easier to read a complex as
> (1+2i) than to read it as complex(1,2). In large array printouts,
> that's something that makes a lot of difference.


If "in favor of" adding support for imaginaries to Python's
syntax then I disagree.  We could still have the first be
str() and the second be repr().  Though there is an advantage
that the natural (after years of education) human representation
matches the Python one.

As you point out, that is not the case for decimals.

Suppose Python3.0 goes the other way and uses decimal as
the native number type and requires some suffix for floats?

   x = 3.04      # this is a decimal
   y = 3.14159f  # this is an IEEE 754 float

>>But I've never actually used complex
>>for any of my Python work and suspect that I
>>wouldn't have a problem using (say)
>>   cmath.complex(1.12, 2.9)
>>instead if I did.
> 
> 
> But you sure find it more convenient to type (1.12+2.9i), don't you?

My point is that I find it more convient that most
objects get created via the same call-style interface.
I would find

   s = url"http://www.python.org/"

more convenient to type than

   s = urllib.urlopen("http://www.python.org/").read()

Doesn't mean I want it.

				Andrew
				dalke at dalkescientific.com