PY3 compatibility for itertools

[Wurschdhaud]

Description

Fixes itertools compatibility

---

Checklist

Before submitting your pull request, ensure the following requirements are met:

• Code follows the PEP 8 style guide.
• Code has been formatted with Black using the command:

  pipenv run black {source_file_or_directory}

• Changes are tested and verified to work as expected. - only partially!

---

Related Issues

If applicable, link the issues resolved by this pull request:

• Resolves [Bug]: output.print_table() won't work for IPY3 #2810

---

Additional Notes

The table won't show up in IPY3 unless i put a empty print statement before end of the print_table function - no idea why. IPY2 works fine. Like so:

        table = header + justifier + rows
        print("")
        self.print_md('### {title}'.format(title=title))
        self.print_md(table)

---

Thank you for contributing to pyRevit! 🎉

[devloai]

PR Summary:

Fixes itertools compatibility for IronPython 3 by replacing the deprecated izip_longest import. The change conditionally imports izip_longest from itertools for PY2 and zip_longest as izip_longest for PY3, resolving the AttributeError that prevented print_table() from working in IPY3.

Review Summary:

This is a focused bug fix that correctly addresses the itertools compatibility issue reported in #2810. The implementation follows established patterns in the pyrevit.compat module and maintains backward compatibility. The change is minimal, targeted, and directly resolves the AttributeError without introducing complexity or breaking existing functionality.

Follow-up suggestions:

@devloai add unit tests for the print_table() function to ensure compatibility across both IronPython 2 and 3

[Wurschdhaud]

https://github.com/IronLanguages/ironpython3/wiki/Upgrading-from-IronPython2#redirecting-output

This might have sth to do with that weird print statement?

[Wurschdhaud]

AI to the rescue:

Markdown not rendered in IPy 3.4 → Output buffering / stream behavior change (binary vs text writer)
print("") works → Forces stdout flush or stream initialization
Real fix → Add sys.stdout.flush() after printing in print_md()
Best fix if hosting IronPython → Configure ConsoleSupportLevel = SupportLevel.Basic in host code

I can confirm that this inside the output ini works:

import sys

@staticmethod
def print_md(md_str):
    ...
    print(html_code, end="")
    sys.stdout.flush()  # <<< Add this line

and i assume that changing dev>modules>pyReviLabs.ironpython3>Src>DLR>Src>Microsoft.Scripting>Runtime>ShareIO.cs
from SupportLevel.Full to SupportLevel.Basic might also solve this issue

But what are the downsides of either solution?

[jmcouffin]

you could add and test adding

if PY3:
    sys.stdout.flush()

to the print_md function.
While I agree it may be smarter to fix it at the ShareIO level, it may be much more difficult to see the side effects, and would require extensive testing.

thoughts @sanzoghenzo @dosymep

[sanzoghenzo]

while you're at it, can you drop the zipper variable altogether and just call izip_longest directly?

I don't see any benefit of using that support variable.

thoughts @sanzoghenzo @dosymep

I would go with this

Best fix if hosting IronPython → Configure ConsoleSupportLevel = SupportLevel.Basic in host code

since one of the goals I had in mind when we talked about isolating the plugin to avoid DLL hell was to drop our custom libraries and leverage the upstream ones via nuget (just to avoid having to remember what we patched when we need to update it) and use ilrepack or something like that. But I'm not the guru on this matter 😅

[sanzoghenzo]

On a more general note, I believe we should start to rely more and more on six. It's already in the site-package, but it may be worth to update it to 1.17.0, which is the latest release from december 2024, and will be the last one supporting python 3.3 through 3.5.

[Wurschdhaud]

So I tried it with six, but i guess that site-package is loaded later? Which is a shame, would have made it more compact.

[sanzoghenzo]

site-package should be added to the path by the ironpython executor, so six should be there...

What did you try? Does import six raise an error?

[Wurschdhaud]

Yeah, i tried both:
import six for testing
as well as
from six.moves import zip_longest.

During startup i get the ImportError: No module named six, and pyrevit doesnt load at all.

if i add it later, and hit reload in the pyrevit tab, it works

[sanzoghenzo]

Oh, I didn't think about pyrevitloader, it also loads pyrevit library.
Since is a single module, we could copy it directly inside pyrevitlib.

But I believe we can postpone it to another PR 😉

[Wurschdhaud]

So should i drop this PR and wait for the pyrevitloader→pyrevitlib fix?

[sanzoghenzo]

So should i drop this PR and wait for the pyrevitloader→pyrevitlib fix?

Sorry for not being clear, the PR is OK as it is.

I was referring to introducing six, it should be done extensively on the entire codebase, so I believe it is out of scope of this PR and can be postponed.

Unless you want to fix this right away!

[github-actions]

📦 New work-in-progress (wip) builds are available for 5.2.0.25272+2017-wip

[github-actions]

📦 New work-in-progress (wip) builds are available for 5.2.0.25272+2149-wip

[github-actions]

📦 New work-in-progress (wip) builds are available for 5.2.0.25274+1734-wip

[github-actions]

📦 New work-in-progress (wip) builds are available for 5.2.0.25277+1425-wip

[github-actions]

📦 New work-in-progress (wip) builds are available for 5.2.0.25277+1427-wip