Hello :). My typing hand really hurts so I made this a video, hope that’s ok 
(Sorry if my voice is annoying)
The number with a trailing e-17 is displayed in scientific notation. This trailing marker represents 10^-17, which is multiplied with the preceding number, to encode a value that, in this case, approaches zero.
To see this clearly in familiar notation, try:
print("{:.50f}".format(CamRotEuler[1]))
When you call print on any Euler object, you invoke its str method, which provides the print function with the relevant string representation of the object. That method seems to round/truncate down to 4 decimal places ("{:.4f}"), which explains the displayed zeroes, but the number itself is not exactly zero (just really, really small).
PS:
scene.objects should not be used to look up object references on every single frame. You should think of it as a convenience structure, which allows you to get some initial references, at initialization; Once you have them initially, you can save them as an object property, and use them from there, effectively avoiding the slow-down that would otherwise follow.
Thanks for the explanation Goran :D. I thought this was some massive bug in python or something, turns out it’s a simple misunderstanding lol. And yeah, that’s pretty much what I do with scene.objects, I take a few of the most used objects and store them inside of the object CharCamera so I can access them later. Just wondering, has there been any talk of speeding up scene.objects? It’s something that sort of creeps up on you, and cost me about a day reworking everything(As in huge forest scenes) to have less objects.
Thanks for your help 
I remember a thread where users requested this speed up, but I think it would be a mistake to grant their wish, because it would just reinforce the bad practice of constantly referencing objects by name.
Unless there’s no other way to get the relevant references, scene.objects should not be used, as implied by the fact that game objects are not guaranteed to have unique names.
I guess my point was: You don’t really need to look up objects by name, so there’s no need for a fast lookup structure to do that.
Just store and use the references themselves.