'{}' matches nonempty namespaces in objectify

[KT]

Empty namespace acts as a wildcard when using numbered indices. Both lookup and assignment are affected.

XML:

    <aaa:Parent xmlns:aaa="urn:aaa" xmlns:bbb="urn:bbb">
        <bbb:Child>foo</bbb:Child>
        <Child>foox</Child>
    </aaa:Parent>

Code:

    print(root['{}Child'][0])
    print(root['{}Child'][1])

Expected result:

    foox
    IndexError: 1

Actual result:

    foo
    foox

Python : (2, 7, 6, 0)
lxml.etree : (3, 4, 1, 0)
libxml used : (2, 9, 0)
libxml compiled : (2, 9, 0)
libxslt used : (1, 1, 28)
libxslt compiled : (1, 1, 28)

[scoder (scoder)]

Yes, looks wrong. Would be a regression, though - it was supposed to be fixed in 2.3.

http://thread.gmane.org/gmane.comp.python.lxml.devel/5730/focus=5750

http://lxml.de/2.3/changes-2.3.1.html#id2

[KT (bintoro)]

It's a different scenario. The case addressed by the 2.3 fix still works:

  <aaa:Parent xmlns:aaa="urn:aaa" xmlns:bbb="urn:bbb">
    <bbb:Child>foo</bbb:Child>
    <Child>foox</Child>
  </aaa:Parent>

  >>> root['{}Child']
  foox

This bug is about '{}' matching *too many things* (i.e., all namespaces) when using the numeric index notation. The bug reported in the newsgroup thread was about '{}' forcing the parent namespace and matching that only.

Compare the above result with this:

  >>> root['{}Child'][0]
  foo

Of course, index 0 should return 'foox' just like when the index is omitted.

By contrast, bug 1402432 (now marked as a dupe) was indeed the __setitem__ parallel of the old bug (forcing the parent namespace). Because of that I reported these two separately, not knowing whether these share the same root cause.