The findall method for ElementTree.Element handles namespace prefixes by tokenising the path and inserting the full namespace in braces based on entries in a dictionary.

Unfortunately, this does not work for a namespace without a prefix, so if you have files containing namespaces with and without prefixes, you still need to manually add the namespace url for the unprefixed path.

The function xpath_tokenizer checks to see if tokens contain a colon and only adds in the namespace url in that instance.

This could be changed to add the url if their is a colon, or if there is not, and the empty string key is present in the namespaces dictionary.

I agree that this is a recurring irritant.

Agreed that this should be added. I think the key should be None, though, not the empty string. I attached a quick patch for lxml's corresponding file. It's mostly the same for ET.

Patch replaced by pull request.
#1823

New changeset e9927e1 by Stefan Behnel in branch 'master':
bpo-30485: support a default prefix mapping in ElementPath by passing None as prefix (bpo-1823)
e9927e1

I've merged the PR. It matches the implementation that has been released in lxml almost two years ago.

I am not sure but this commit seems to have broken Azure CI on master for Windows. The build checks were green when the PR while merging. I can see the ValueError added in e9927e1 raised in the below CI log and it's occurring consistently

https://dev.azure.com/Python/cpython/_build/results?buildId=40862&view=logs&jobId=0fcf9c9b-89fc-526f-8708-363e467e119e&taskId=ae411532-3d9e-5cb2-bb36-07007cc5bb48&lineStart=37&lineEnd=38&colStart=1&colEnd=1

Interesting. Thanks for investigating this. It looks like the script "appxmanifest.py" uses an empty string as prefix for a lookup:

File "D:\a\1\s\PC\layout\support\appxmanifest.py", line 407, in get_appxmanifest
node = xml.find("m:Identity", NS)

I don't know where that script comes from, but it suggests that strictly rejecting this kind of invalid library usage might not be the right thing to do for now. It seems to be a case where users pass an arbitrary prefix-namespace dict into .find() that they happen to have lying around, expecting unused mappings to be ignored. I pushed a PR that removes the exception for now.

The relevant line is at

The script seems to generally assume that "" is a good representation for "no prefix", i.e. the default namespace, although that is IMHO more correctly represented as None. It's not very likely that this is the only script out there that makes that assumption.

In fact, this might not be an entirely stupid assumption, given that None doesn't sort together with strings, for example. And sorting prefixes is not an unusual thing to do.

That makes it a case of "practicality beats purity", I guess …

I'll change the implementation to allow empty strings.

New changeset 3c5a858 by Stefan Behnel in branch 'master':
bpo-30485: Re-allow empty strings in ElementPath namespace mappings since they might actually be harmless and unused (and thus went undetected previously). (bpo-12830)
3c5a858

I don't recall where I got the empty string from, but it's certainly what I've used there for a while. Maybe it's required in register_namespace() to set the default namespace?

I submitted a PR that changes the API back to an empty string. While lxml uses None here, an all-strings mapping is simply more convenient. I will start supporting both in lxml from the next release.

Comments welcome.

New changeset e8113f5 by Stefan Behnel in branch 'master':
bpo-30485: Change the prefix for defining the default namespace in ElementPath from None to '' since there is existing code that uses that and it's more convenient to have an all-string-keys dict (e.g. when sorting items etc.). (bpo-12860)
e8113f5