Python Forum

Full Version: testing for Decimal w/o importing decimal every time
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
a function i wrote really should be acting a bit differently when the value it is given is type decimal.Decimal. but almost all calls will be another type. so i'd rather not be importing decimal every time the function gets used. the following code looks like it might accomplish the test without the need for the type to be imported:
    if 'radix' in dir(value):
        ...
is this valid to do? would this work?
Why not if hasattr(x, 'radix'):...?
Wouldn't
if type(value) == "<class 'decimal.Decimal'>":
    print('is decimal')
be better?
IMHO, importing it is much better than writing some weird test for type. Then depending on how different the function should be you can use @functools.singledispatch(yet another import)
(May-06-2019, 12:04 AM)Gribouillis Wrote: [ -> ]Why not if hasattr(x, 'radix'):...?

better way to code it; same idea. i guess this technique risks a user-defined object that has attribute 'radix' for whatever reason.

(May-06-2019, 04:39 AM)buran Wrote: [ -> ]IMHO, importing it is much better than writing some weird test for type. Then depending on how different the function should be you can use @functools.singledispatch(yet another import)

i think that would either end up with a lot of extra code, or a more twisty maze of function calls i would have to figure out to avoid the duplication. it's just a difference in how i shift the decimal point around when there is a whole value there during conversion to string. about 80 lines of code does the same thing for (int,float,Decimal). it's complex when .imag is non-zero and Fraction that will be my future mess.
(May-06-2019, 06:42 AM)Skaperen Wrote: [ -> ]i think that would either end up with a lot of extra code, or a more twisty maze of function calls
I don't know your code, so you should know better and I just speculate, but the whole point of singledispatch is to have same function call and it will be different function depending on first argument type.

(May-06-2019, 06:42 AM)Skaperen Wrote: [ -> ]it's just a difference in how i shift the decimal point around when there is a whole value there during conversion to string. about 80 lines of code does the same thing for (int,float,Decimal). it's complex when .imag is non-zero and Fraction that will be my future mess.

Again, I can just speculate, but I think it's mess exactly because you try to keep everything in one function and thus use a lot of if statements depending on type. I think, even with some repeating parts, that you cannot put in a separate function to avoid repeting, it will be easier and you will end up with more readable and structured code to deal if for each type you have different function and it's strightforward
buran Wrote:you try to keep everything in one function and thus use a lot of if statements depending on type
which is a blatant non pythonic attitude.
(May-06-2019, 08:57 AM)buran Wrote: [ -> ]Again, I can just speculate, but I think it's mess exactly because you try to keep everything in one function and thus use a lot of if statements depending on type. I think, even with some repeating parts, that you cannot put in a separate function to avoid repeting, it will be easier and you will end up with more readable and structured code to deal if for each type you have different function and it's strightforward

in this case there is just one if test for the case of Decimal to tweak the formatting position a bit. the rest of it is the same, though i will need to do more when i include complex and probably Fraction.

(May-06-2019, 10:12 AM)Gribouillis Wrote: [ -> ]
buran Wrote:you try to keep everything in one function and thus use a lot of if statements depending on type
which is a blatant non pythonic attitude.
for the major types there's about 80 lines of code where one of the types is handled slightly different for certain values. i don't want to have 4 copies of this code (where 1 of them has one line slightly different). if i have to make a general logic change, i would have to keep all copies in sync ... increased maintenance. and reading the code of 6 to 8 pages worth the reader won't necessarily see the difference right away. the ideal would be to have a single expression with a test for type of argument data that the compiler can isolate and make the 4 type-selected functions for.

i'm still a firm believer in the idea that a single thing should be expressed just once no matter how many places it is used, especially when differences in different places can throw things out of sync. and i believe in making code clear and easy to read, including the difference in logic when that difference may be too subtle to notice.

the cost of development and the cost of maintenance are what i try to reduce the most. the cost of others trying to learn from this code is a secondary cost to reduce.