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})
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!
--
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 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
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
--
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
