# KNIME to Python Exporter: Roadmap for Additional Node Support **URL:** \ **Category:** Node Development\ **Tags:** python\ **Created:** [April 29, 2026, 8:05pm UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874 "2026-04-29T20:05:49Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![VitaliiKaplan](https://forum-cdn.knime.com/user_avatar/forum.knime.com/vitaliikaplan/32/82574_2.png) [@VitaliiKaplan](https://forum.knime.com/u/VitaliiKaplan)\ **Post date:** [April 29, 2026, 8:05pm UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/1 "2026-04-29T20:05:49Z")
Dear KNIME users, I want to thank you for using k2pweb and knime2py and share news from > [@KNIME to Python exporter](https://forum.knime.com/t/knime-to-python-exporter/89901): > > Friends, I’m happy to share with you my new open-source project – knime2py. [GitHub - vitaly-chibrikov/knime2py: KNIME project to Python workbook converter](https://github.com/vitaly-chibrikov/knime2py) If you work in KNIME you know how fast new prototype of DS project can be created in it. And, at the same time, how complex already developed KNIME project can be. But maybe you, as I am, fill the lack of ability to export your KNIME project to .py or .ipynb files. So, I decided to start my new open-source project “knime2py” which is a code… During the last two months, I collected workflow profiles and web service usage logs. This helped me fix one race-condition issue in [the platform](https://k2pweb.org/) and gather statistics about node usage in different projects. Now I have data showing which nodes are used most frequently, so I can focus on supporting them. I created four tasks in the project’s task tracker. Each task contains five nodes that I need to implement in the release. These are the most frequent nodes used by you that are not yet supported by knime2py. > **[knime2py tasks board • vitalii-kaplan](https://github.com/users/vitalii-kaplan/projects/1/views/1)** > > Tasks board for knime2py open-source project. Here is the list: KNIME factory for the node, and the number of times it was used. ```auto org.knime.base.node.preproc.groupby.GroupByNodeFactory, 171 org.knime.base.node.preproc.joiner3.Joiner3NodeFactory, 97 org.knime.js.base.node.quickform.filter.value.ValueFilterQuickFormNodeFactory, 94 org.knime.base.node.preproc.constantvalue.ConstantValueColumnNodeFactory, 82 org.knime.base.node.rules.engine.RuleEngineFilterNodeFactory, 60 org.knime.base.node.preproc.rename.RenameNodeFactory, 39 org.knime.base.node.preproc.filter.row.RowFilterNodeFactory, 38 org.knime.database.node.io.reader.query.DBQueryReaderNodeFactory, 37 org.knime.database.extension.postgres.node.connector.PostgreSQLDBConnectorNodeFactory, 36 org.knime.base.node.preproc.colcombine2.ColCombine2NodeFactory, 32 org.knime.base.node.preproc.pivot.Pivot2NodeFactory, 29 org.knime.base.node.preproc.columnresorter.ColumnResorterNodeFactory, 26 org.knime.base.node.preproc.unpivot2.Unpivot2NodeFactory, 26 org.knime.expressions.base.node.formulas.FormulasNodeFactory, 12 org.knime.time.node.calculate.datetimedifference.DateTimeDifferenceNodeFactory, 10 org.knime.time.node.manipulate.datetimeshift.DateTimeShiftNodeFactory, 8 org.knime.base.node.preproc.cellsplit2.CellSplitter2NodeFactory, 7 org.knime.python3.scripting.nodes2.script.PythonScriptNodeFactory, 7 org.knime.base.node.preproc.duplicates.DuplicateRowFilterNodeFactory, 6 org.knime.base.node.preproc.sorter.SorterNodeFactory, 5 ``` Thank you for your participation. P.S. If the node you need is not in the list, please contact me directly here or on Instagram. I will include support for your node in a future release. ---
**Author:** ![joh\_elf](https://forum-cdn.knime.com/letter_avatar_proxy/v4/letter/j/ed655f/32.png) [@joh\_elf](https://forum.knime.com/u/joh_elf)\ **Post date:** [April 30, 2026, 8:54am UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/2 "2026-04-30T08:54:35Z")
Hi @VitaliiKaplan, thanks for sharing your project. I really like the idea! Since the other thread [KNIME to Python exporter - #10](https://forum.knime.com/t/knime-to-python-exporter/89901/10) has been closed, I’ll try to continue with the discussion on the data processing here. @Add94: Thanks for sharing your insights on the data processing backends. Instead of going for DuckDb, I’d recommend going either for Ibis or Polars. DuckDb might provide a _slightly_ superior performance, but the reason why Python+Pandas became so popular also applies here: Having a clean and easily understandable API to data structures is much more important than leveraging the last 0.1% of computational performance. Polars API is close to Pandas API, thus everyone from novice to data processing specialist will feel more confident with using Polars than DuckDB. SQL is only used by few data scientists, especially when looking at the typical user base of Knime. Furthermore I’ve got the _feeling_ that Polars is evolving faster than DuckDB, especially by moving towards distributed computing. Best regards, Johannes ---
**Author:** ![VitaliiKaplan](https://forum-cdn.knime.com/user_avatar/forum.knime.com/vitaliikaplan/32/82574_2.png) [@VitaliiKaplan](https://forum.knime.com/u/VitaliiKaplan)\ **Post date:** [April 30, 2026, 8:57am UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/3 "2026-04-30T08:57:31Z")
> [@VitaliiKaplan](#): > > on Instagram Sorry, on LinkedIn :o) ---
**Author:** ![VitaliiKaplan](https://forum-cdn.knime.com/user_avatar/forum.knime.com/vitaliikaplan/32/82574_2.png) [@VitaliiKaplan](https://forum.knime.com/u/VitaliiKaplan)\ **Post date:** [April 30, 2026, 9:07am UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/4 "2026-04-30T09:07:53Z")
Good idea. First, I need to learn what the Polaris API is. Technically, since my development process is now strongly supported by AI code assistant, adding a new API may not be too difficult. However, I think it is better to implement exporters for more nodes first. As you can see, users of the web service requested Python code for the not-yet-supported “GroupBy” node 171 times during the last two months. So, I am going to focus on those nodes first. I have added a task about it to the task-tracker. ---
**Author:** ![Add94](https://forum-cdn.knime.com/user_avatar/forum.knime.com/add94/32/77533_2.png) [@Add94](https://forum.knime.com/u/Add94)\ **Post date:** [April 30, 2026, 1:05pm UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/5 "2026-04-30T13:05:54Z")
Thanks a lot Johannes! Ultimately it’s all down to a preference - some would claim (myself included 🙂 ) that SQL is the universal data language, some would say that dataframe API approach is superior. Ibis is a sort of a middle ground as it tries to please both groups by introducing a swappable execution back-end philosophy. One thing I would be reluctant to agree with is the development roadmap claim (“polars evolving faster”). Duckdb has a huge ecosystem of extensions and community contributions , invests time and resources into their own lakehouse format. Polars mostly develops by their core team, focuses on their core API improvements , GPU execution and their cloud offering - very different philosophies. I’d argue duckdb is much more versatile when it comes to use cases. Polars is also less mature in the sense of how robust the engine is (out of core processing, disk spilling etc) - those are not 0.1% improvements, it’s either you process a query or hit an OOM error. Polars is nowhere near the capability of processing a TB query on a standard laptop. I understand this might be a ‘tail’ use case vs a typical data scientist workload though. In the end, knime2py is a great project and even being able to export workflows to pandas would be huge! This is a great contribution to the community, thank you for taking on this project @VitaliiKaplan ---
**Author:** ![joh\_elf](https://forum-cdn.knime.com/letter_avatar_proxy/v4/letter/j/ed655f/32.png) [@joh\_elf](https://forum.knime.com/u/joh_elf)\ **Post date:** [April 30, 2026, 1:28pm UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/6 "2026-04-30T13:28:15Z")
I agree that SQL is the universal data language and everyone _should_ be able to use it. But reality hits hard: Only few of those working with data _really_ know how to write SQL, while many understand the “more expressive” Pandas/Polars APIs. Ok, thanks a lot for your insights! That’s quite interesting to read and sounds reasonable. Maybe I’ll have another shot at DuckDb. ---
**Author:** ![VitaliiKaplan](https://forum-cdn.knime.com/user_avatar/forum.knime.com/vitaliikaplan/32/82574_2.png) [@VitaliiKaplan](https://forum.knime.com/u/VitaliiKaplan)\ **Post date:** [May 1, 2026, 8:47pm UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/7 "2026-05-01T20:47:21Z")
Friends, I’ve published an article on Medium about knime2py: [Can LLMs Write Code That Writes Code?](https://medium.com/@vitalii.v.kaplan/can-llms-write-code-that-writes-code-10c0b60461ee) If you do not have a Medium account, you can read it here: > ---
**Author:** ![system](https://forum-cdn.knime.com/uploads/default/original/1X/ab3ccf34482a0329361734a18199390177204f15.png) [@system](https://forum.knime.com/u/system)\ **Post date:** [July 30, 2026, 8:47pm UTC](https://forum.knime.com/t/knime-to-python-exporter-roadmap-for-additional-node-support/91874/8 "2026-07-30T20:47:55Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.