> Yes, but it would be rather pointless to make one if my analysis is > incorrect or it would be bounced for some non-technical reason so I emailed > it for discussion. I'm also unsure if switching to exact matching on a > normalized string instead of substring matching is good (well... it is good > for performance, but might not be good for UI).
That's something completely different. I thought you were saying that the Cheeseshop should block conflicting registrations. To implement that, you only have to perform any normalization when a new project is registered. There are roughly three new registrations per day, so performance is irrelevant here. Matching on lookup is rather a convenience to users; they can put in a misspelled string and still find the package. OTOH, the search interface already does case-insensitive matching; I doubt that doing it in the URL adds much convenience. OTOH, it does add performance (not convenience) to setuptools users, as setuptools could stop downloading the complete package list to find the match. But these are unrelated; if you want to contribute, it might be best to just focus on the part that really worries you (namely the security risk of conflicting registrations). Regards, Martin _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
