any vs default have different semantics, should we omit it in those cases?

Hmm, we are omitting them here right (i.e. !matches)? My understanding is we'd like to surface only the segments a user explicitly set, and these both represent (afaik) no explicit version constraint.

Sorry, I meant "should we be omitting it"

That's fair. I think I'd expect those to be filtered in the unset_defaults method instead though?

It's a possible foot gun, in the sense that they have different semantics so omitting them could have a different result, but I can't really think of a concrete situation where this would occur. Emitting any would probably mess up the key parser anyway? :/ I'm fine omitting them until there's a problem.

That's fair. I think I'd expect those to be filtered in the unset_defaults method instead though?

Yeah agreed, I think simplified_display should be simple in that it just filters out None values.

It's a possible foot gun, in the sense that they have different semantics so omitting them could have a different result, but I can't really think of a concrete situation where this would occur. Emitting any would probably mess up the key parser anyway? :/ I'm fine omitting them until there's a problem.

Looks like omitting anything will screw up the key parser (it expects 5 components), but since what we pass into uv python upgrade doesn't go through the key parsing flow, I think it's fine? 🤔 Especially sine omitting any/default here doesn't have any semantic loss, but I understand how if we use this for some other purpose there could be issues.

Just as a note

Looks like omitting anything will screw up the key parser (it expects 5 components),

I was referring to PythonDownloadRequest, which is how a request for a "key" is formed and does support missing components since #14399

since what we pass into uv python upgrade doesn't go through the key parsing flow

It could, e.g., we use the generic parser

so if you request uv python upgrade 3.14-x86_64 or something that goes through the key parsing flow

Hey @terror and @zanieb, it's problematic to not always pass the python_downloads_json_url as it may warn users about versions that are not really available to them, as it does not look at the actual json that they use (if it's configured)

I think it should be passed, or not try to warn at all if python_downloads_json_url is configured

Thanks, I missed that

#16711