parse_match() stopped returning distinct results for 'foo' and 'foo:*'

[mgorny]

In [1]: from pkgcore.util.parserestrict import parse_match                                                                                         

In [2]: parse_match('bar:*')                                                                                                                       
Out[2]: <PackageDep attr='package' restriction=<StrExactMatch 'bar' @0x7fdf61cae890> @0x7fdf614009b0>

In [3]: parse_match('bar')                                                                                                                         
Out[3]: <PackageDep attr='package' restriction=<StrExactMatch 'bar' @0x7fdf61cae890> @0x7fdf614009b0>

In [4]: parse_match('bar:=')                                                                                                                       
Out[4]: <AndRestriction negate=False type='package' finalized=True restrictions=(<SlotDep attr='slot' restriction=<StrExactMatch '=' @0x7fdf624a55f0> @0x7fdf61ca20b0>, <PackageDep attr='package' restriction=<StrExactMatch 'bar' @0x7fdf61cae890> @0x7fdf614009b0>) @0x7fdf624a5650>

In the past, bar:* used to return AndRestriction with SlotDep as well. I'm using this to construct 'unqualified atoms' in gentoopm, and losing this ability means I'm no longer able to accurately represent user input.

[ferringb]

Offhand, I'm not entirely in agreement that ':=' should be optimize out. Admittedly it makes fuck-all sense for pquery, but that's an explicit slot operator; the atom object shouldn't drop that.

As to parse_match giving different atoms based upon invocation- it's supposed to; your ask is better phrased as "should parse_match rewrite input" (things like dropping slot operators) based on context, which phrased that way: it's not a simple 'yes'.

My personal inclination here is that 'no' is the correct answer for parse_match, but we should find a solution that address your base need.