Отступы в lxml.etree.tostring () различаются для Mac и Linux - PullRequest
2 голосов
/ 04 января 2012

В Python lxml.etree.tostring () по-разному отступает для Mac и Linux - отступы вдвое длиннее, чем в Linux.Это взрывает мои модульные тесты.

Очевидно, lxml.etree не предоставляет никакого пути для установки значений отступа по умолчанию.

Кто-нибудь имеет какие-либо идеи, что здесь может происходить?

ИЗМЕНЕНО ДЛЯ ДОБАВЛЕНИЯ КОДА:

Я уверен, что код тот же, компьютеры делятся им через github.

Вот тестовый код:

    chk = """\
<field>
      <id>7135260</id>
      <name>lastname</name>
      <label>Last Name</label>
      <type/>
    </field>"""

        res = etree.tostring((xml_obj.xpath(xp_str))[0], pretty_print=True)

        self.assertMultiLineEqual(
            chk,
            res.rstrip()
        )

Это проходит в Linux, но не на Mac, с таким отчетом об ошибке:

-       <id>7135260</id>
+             <id>7135260</id>
? ++++++
-       <name>lastname</name>
+             <name>lastname</name>
? ++++++
-       <label>Last Name</label>
+             <label>Last Name</label>
? ++++++
-       <type/>
+             <type/>
? ++++++
-     </field>
+         </field>
? ++++

НО, когда я изолирую код, вызывающий сбой, он выдает одинаковое на обоих:

data_str    =   """\
<response>
  <fields>
    <field>
      <id>7135259</id>
      <name>firstname</name>
      <label>First Name</label>
      <type/>
    </field>
    <field>
      <id>7135260</id>
      <name>lastname</name>
      <label>Last Name</label>
      <type/>
    </field>
  </fields>
  <status>success</status>
</response>
"""

data_xml    =   etree.fromstring(data_str)

res = etree.tostring(
        (data_xml.xpath('//*[name="lastname"]/name/..'))[0], 
        pretty_print=True)

print res

Это дает одинаковые отступы на обеих платформах.

Так что, какой бы странной ни была странность, она находится в / вызвана unittest2.Это, вероятно, не очень хороший вопрос на данный момент.

ДОПОЛНИТЕЛЬНОЕ РЕДАКТИРОВАНИЕ:

Когда я оборачиваю элементы сравнения в repr (), я получаю это:

- '<field>\n      <id>7135260</id>\n      <name>lastname</name>\n      <label>Last Name</label>\n      <type/>\n    </field>'
+ '<field>\n            <id>7135260</id>\n            <name>lastname</name>\n            <label>Last Name</label>\n            <type/>\n        </field>\n        \n'
?           ++++++                        ++++++                                   ++++++                                ++++++             ++++        ++++++++++++

Этот вывод на самом деле приходит в одну строку.Я вставил разрывы строк сначала + знак и?символ.

Я искал результаты теста для вкладок ('\ t').Я уверен, что я не вставляю символы табуляции, я использую vi w / 'set expandtab'.

Ответы [ 2 ]

2 голосов
/ 04 января 2012

Используете ли вы точно одинаковые аргументы для tostring() в каждом случае?Вы пытались отключить отступ, чтобы проверить, действительно ли это проблема?

Покажите нам свой код, который вызывает tostring ().Создайте небольшое дерево примеров и покажите нам результат print len ​​(result_of_tostring), repr (result_of_tostring) на каждой ОС.Также расскажите нам о том, как вы переносите результат в другую систему для сравнения, и покажите нам код для этого сравнения.

Обновление : отступ вашей строки "chk" выглядит подозрительно.Я полагаю, что в lxml нет ничего плохого, и у вас есть экспериментальная ошибка с пробелами.Вы удалили все TAB из своего кода?Вы уверены, что не открыли / не сохранили свой код в редакторе, который заменяет вкладки пробелами или наоборот? Почему бы вам не использовать repr (), как предлагалось, чтобы точно / однозначно показать, что такое неравные строки?

Обновление 2 : поиск по исходному коду для вкладок.Ваш отображаемый источник для "chk" имеет отступ 6 для большинства строк.

1 голос
/ 04 января 2012

Вы можете написать метод assertXMLEqual, который просто удаляет отступ перед сравнением.Ваши тесты должны проверять правильность xml dom из тестируемой вами функции, то, как она сериализуется и имеет отступ, не имеет к этому отношения.

...