First of all, like Steven Rumbalski said, "PEP8 doesn't address this question", so it is a matter of personal preference.
I would use a similar but not identical format as your format 3. Here is mine, and why.
my_dictionary = { # Don't think dict(...) notation has more readability
"key1": 1, # Indent by one press of TAB (i.e. 4 spaces)
"key2": 2, # Same indentation scale as above
"key3": 3, # Keep this final comma, so that future addition won't show up as 2-lines change in code diff
} # My favorite: SAME indentation AS ABOVE, to emphasize this bracket is still part of the above code block!
the_next_line_of_code() # Otherwise the previous line would look like the begin of this part of code
bad_example = {
"foo": "bar", # Don't do this. Unnecessary indentation wastes screen space
"hello": "world" # Don't do this. Omitting the comma is not good.
} # You see? This line visually "joins" the next line when in a glance
the_next_line_of_code()
btw_this_is_a_function_with_long_name_or_with_lots_of_parameters(
foo='hello world', # So I put one parameter per line
bar=123, # And yeah, this extra comma here is harmless too;
# I bet not many people knew/tried this.
# Oh did I just show you how to write
# multiple-line inline comment here?
# Basically, same indentation forms a natural paragraph.
) # Indentation here. Same idea as the long dict case.
the_next_line_of_code()
# By the way, now you see how I prefer inline comment to document the very line.
# I think this inline style is more compact.
# Otherwise you will need extra blank line to split the comment and its code from others.
some_normal_code()
# hi this function is blah blah
some_code_need_extra_explanation()
some_normal_code()