It does rather depend on what you mean by first. In Python 3.6, entries in a dictionary are ordered by the key, but probably not quite in the way you expect.
To take your example:
>>> data = {"Key1" : "Value1", "Key2" : "Value2"}
Now add the key 0
:
>>> data[0] = "Value0"
>>> data
{'Key1': 'Value1', 'Key2': 'Value2', 0: 'Value0'}
So the zero comes at the end. But if you construct the dict from scratch, like this:
>>> data = {0: "Value0", "Key1" : "Value1", "Key2" : "Value2"}
you get this result instead
>>> data
{0: 'Value0', 'Key1': 'Value1', 'Key2': 'Value2'}
This illustrates the principle that you should not depend on the ordering, which is defined only by the dict implementation, which, in CPython 3.6 and later, is order of entry. To illustrate that point in a different way:
>>> data = {0: "Value0", "Key1" : "Value1", "Key2" : "Value2"}
>>> sorted(data.keys())
Traceback (most recent call last):
File "<pyshell#42>", line 1, in <module>
sorted(data.keys())
TypeError: '<' not supported between instances of 'str' and 'int'
Guido has this to say on the subject:
I'd like to handwave on the ordering of ... dicts. Yes, in
CPython 3.6 and in PyPy they are all ordered, but it's an
implementation detail. I don't want to force all other
implementations to follow suit. I also don't want too many people
start depending on this, since their code will break in 3.5. (Code
that needs to depend on the ordering of keyword args or class
attributes should be relatively uncommon; but people will start to
depend on the ordering of all dicts all too easily. I want to remind
them that they are taking a risk, and their code won't be backwards
compatible.)
The full post is here.