[lxml-dev] Bug: type annotation namespace-prefix goes missing

[Stefan Behnel]

Hi Holger,

jholg at gmx.de wrote:
>  Here's without any objectify-ism:
[...]
>  FWIW this also fails with older versions, but:
>  - 1.2.1 fails with the objectify version, but not the "pure" etree one
>  - 1.3beta  fails with the objectify version, but not the "pure" etree one

Hmm, that's interesting. I never thought we were *that* robust before. ;)

Anyway, I started by making objectify a bit more robust here, as slice
assignment tends to have more corner cases than you might think. The problems
usually arise when you replace an Element's children with themselves or with
their own siblings (as you did in your example). I changed the implementation
to copy *all* source nodes first, and *then* start replacing them in the
target slice. Previously, they were copied over one by one while doing the
replacements, so now you're on the safe side here.

@Christian, please check out the current SVN trunk to see if it works for you
(and take care you use Cython 0.9.6.11*b* to build it).

BTW, I also removed the support for things like this:

  el.a[:] = [[el1, el2], [el3, el4]]

which behaved just like

  el.a[:] = [el1, el2, el3, el4]

although you can still do

  el.a = [el1, el2]

I don't think anyone will really miss the first one, especially as it only
worked for one list level anyway.

Regarding the same problem in etree: I'm not sure, but it looks like libxml2
is behaving in a strange way here. When we copy a node to a new document root
(xmlDocCopyNode), it creates the necessary namespaces on the new node, but in
the example, I seem to be getting something like this back:

  <b name="b1">
    <title xmlns:py="http://codespeak.net/lxml/objectify/pytype"
           py:pytype="str">tit</title>
    <text py:pytype="str">FOO!</text>
  </b>

Note the missing namespace declaration on the second child. It was redeclared
on the first child when the node left the scope of the parent, however, it
doesn't seem to get declared on the second child. But maybe that's just the
serialisation and it looks different internally. I'll have to take a deeper
look into it...

Stefan