Decimal, __radd__, and custom numeric types...
I'm having some issues with decimal.Decimal objects playing nice with custom data types. I have my own matrix and rational classes which implement __add__ and __radd__. They know what to do with Decimal objects and react appropriately. The problem is that they only work with Decimals if the custom type is on the left (and therefore __add__ gets called), but NOT if the Decimal is on the left. The Decimal immediately throws the usual "TypeError: You can interact Decimal only with int, long or Decimal data types." without even trying my __radd__ method to see if my custom type can handle Decimals. >From the Python docs (specifically sections 3.3.7 and 3.3.8), I thought that the left object should try its own __add__, and if it doesn't know what to do, THEN try the right object's __radd__ method. I guess Decimal objects don't do this? Is there a way to change this behavior? If Decimal objects prematurely throw a TypeError before trying the __rop__, is Decimal broken, or was it designed this way? I think I'm missing something... Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
Re: Decimal, __radd__, and custom numeric types...
Thanks for the suggestions and modified module. I will probably just use this "fixed" module to solve my immediate problem. I appreciate your post to python-dev as well; it looks like this may be addressed in a future release. :) Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
True == 1 weirdness
I am maintaining some old code where the programmer used 1 for True because
booleans hadn't been added to Python yet. I'm getting some weird behaviour, so
I created some simple tests to illustrate my issue.
>>> 1 in {1:1}#test1
True
>>> 1 in {1:1} == 1 #test2
False
>>> (1 in {1:1}) == 1 #test3
True
>>> 1 in ({1:1} == 1) #test4
Traceback (most recent call last):
File "", line 1, in
TypeError: argument of type 'bool' is not iterable
>>>
You can see that in the first test we get True as expected. The second test
yield False, because True does not equal 1, apparently. Fair enough. But then
the third test yields True. Weird. Okay, so maybe it was evaluating the right
side first? So I put the parens over to the right and it fails, so that wasn't
it. So why do the second and third test differ?
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wednesday, September 16, 2015 at 8:54:07 AM UTC-4, Jussi Piitulainen wrote:
> The second test, test2, is interpreted (almost) as
>
> (1 in {1:1}) and ({1:1} == 1)
>
> which is obviously False.
Ah, that makes sense. It didn't occur to me that Python would interpret it
that way, and I've been using Python daily for 15 years. I try to avoid
ambiguous chained comparisons, and I use parenthesis even when I don't need
them for clarity. Thanks!
--
https://mail.python.org/mailman/listinfo/python-list
Re: True == 1 weirdness
On Wednesday, September 16, 2015 at 9:08:54 AM UTC-4, jmp wrote: > x = 5 > 3 < x < 10 That's a great example. I use this case all the time and didn't think to apply the same principal to the in/== case. I assumed that "in" was evaluated first, and then the == comparison was made. Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Encryption with Python?
I want to save some sensitive data (passwords, PIN numbers, etc.) to disk in a secure manner in one of my programs. What is the easiest/best way to accomplish strong file encryption in Python? Any modern block cipher will do: AES, Blowfish, etc. I'm not looking for public key stuff; I just want to provide a pass-phrase. I found a few modules out there, but they seem to be all but abandoned. Most seem to have died several years ago. The most promising package is A.M. Kuchling's Python Cryptography Toolkit (http://www.amk.ca/python/code/crypto.html). Is this the defacto Python encryption solution? What does everyone else use? Any other suggestions? The SSLCrypto package (http://www.freenet.org.nz/python/SSLCrypto/) may be a good alternative too, but I am not sure if it is actively maintained. Thanks, Blake -- http://mail.python.org/mailman/listinfo/python-list
