Implement module expression optional fragments

[Peter554]

I've noticed some uses of module expressions in import linter contacts like this:

- domain 
- domain.**

We currently need two entries here, since domain.** does not include domain itself.

This observation motivates the change in this PR, which introduces a syntax for optional fragments within module expressions.

After this PR the above could be reduced to:

- domain[.**]

We didn't really discuss this before @seddonym so feel free to reject this or suggest alternatives!

I wanted to try out a agentic AI, which is the main personal reason for this PR. This PR was generated almost entirely by Claude 3.7 using Zed agentic AI.

Interestingly a module expression domain[.**] now behaves the same as domain with as_package=True.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #228 will not alter performance

_{Comparing Peter554:module-expression-optional-fragment (3bdcec8) with master (8a413e4)}

Summary

✅ 22 untouched benchmarks

[Peter554]

The idea here is that after expanding the module expression, all of the expanded expressions should be valid by the old rules. E.g. a.b[.**] expands to a.b and a.b.**, both of which are valid expressions.

[seddonym]

Interesting to see how AI performs, but I'm not sure about the change itself. If someone is doing this in, say, a forbidden contract, can't they just remove as_packages = False?

[Peter554]

If someone is doing this in, say, a forbidden contract, can't they just remove as_packages = False?

@seddonym Yes they could - but as_packages = False is not available everywhere. E.g. in ignore_imports. Does that influence your opinion?

[seddonym]

I see what you mean. I think of ignore_imports being appropriate for specific exceptions (treated as tech debt burndown) rather than general allow-lists, but I appreciate that's not how everyone uses the tool.

I'm inclined to say that if someone is needing to use ignore_imports for a different purpose, it's a sign that we need a different contract type (in fact a 'protected' contract type is already in the pipeline). I'm also wary of making the expression matching syntax too powerful.

Let's leave this PR open for now - there are a few new contracts in the offing which may make it unnecessary, and plenty of other things that I'd like to concentrate on - in particular speeding up the linter.

Thanks for the idea though.

[Peter554]

Let's leave this PR open for now - there are a few new contracts in the offing which may make it unnecessary, and plenty of other things that I'd like to concentrate on - in particular speeding up the linter.

Okay sounds good to me - I'll put the PR back to draft for now then and we can revisit this if we see a need for it.