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.