Seems like something that would be fairly useful and expected since int/string are already supported its a bit suprising when you find long isn't.. and its small/easy patch. :)
Adding test cases is left as an excercise for the author ;)
The reason Optik doesn't have long or complex types by
default is because I don't see a reason for them. I've
never had to put a complex number on the command-line,
and with the ongoing long/int unification that started
in Python 2.2, I can see less and less reason for
supporting longs explicitly. I really don't see that
a UI requiring "-x 2343L" is going to be very clear to
the non-Python-programmer.
I'm inclined to reject the patch. I will accept it
if you 1) explain why it's necessary for Optik to
support longs out-of-the-box, and 2) add support
for the complex type (for completeness).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off, it does not require the trailing L, long("1234") works perfectly fine.
The int/long unification is promising, but I wonder how many versions it will be till int("reallybignumber") will work? For now any program requiring input of a number larger than sys.maxint must implement their own type="long" support. Admittadly it is much less needed than type=int, but I think it is still important and it is such a small patch I don't see a problem.
The personal need I had for it was that I have a program that uses random.Random, but I want to be able to optionally specify the seed manually in case you want to repeat a previous run.. but the seed usually needs a Long. I'm sure there are other cases where people may need to input large numbers.
When int/long unification fully takes place type=long could print a warning then in version x.y+1 it could be removed, or it could just be set as an alias to "int" forever. (Perhaps it could follow whatever fate is set for the builtin long() func.)
Attached a patch with complex added too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
patch
Logged In: YES
user_id=14422
The reason Optik doesn't have long or complex types by
default is because I don't see a reason for them. I've
never had to put a complex number on the command-line,
and with the ongoing long/int unification that started
in Python 2.2, I can see less and less reason for
supporting longs explicitly. I really don't see that
a UI requiring "-x 2343L" is going to be very clear to
the non-Python-programmer.
I'm inclined to reject the patch. I will accept it
if you 1) explain why it's necessary for Optik to
support longs out-of-the-box, and 2) add support
for the complex type (for completeness).
patch with complex support too
Logged In: YES
user_id=65253
First off, it does not require the trailing L, long("1234") works perfectly fine.
The int/long unification is promising, but I wonder how many versions it will be till int("reallybignumber") will work? For now any program requiring input of a number larger than sys.maxint must implement their own type="long" support. Admittadly it is much less needed than type=int, but I think it is still important and it is such a small patch I don't see a problem.
The personal need I had for it was that I have a program that uses random.Random, but I want to be able to optionally specify the seed manually in case you want to repeat a previous run.. but the seed usually needs a Long. I'm sure there are other cases where people may need to input large numbers.
When int/long unification fully takes place type=long could print a warning then in version x.y+1 it could be removed, or it could just be set as an alias to "int" forever. (Perhaps it could follow whatever fate is set for the builtin long() func.)
Attached a patch with complex added too.
Logged In: YES
user_id=14422
OK, OK, you win. Patch accepted. Look for it in Optik 1.3
later today...