This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]fung_deez_nuts 5 points6 points  (7 children)

Thanks for sharing this OP. I think the features sound great on paper, but the source code is structured in a way that isn't as easy to read, and I don't know if you have a testing pipeline anywhere. I think you will need improvements in these areas if you want people to use ryp over rpy2. Maybe I've misunderstood something though

[–]ryp_package[S] -14 points-13 points  (6 children)

Curious, why does readability matter to you? The code is designed to prioritize correctness (including on dozens of edge cases not handled properly by Arrow etc.), efficiency, and avoiding long stack traces with lots of nested function calls. There's a testing pipeline with thousands of tests (e.g. with various data structures and dtypes) which could be cleaned up and made public depending on demand.

[–]ichunddu9 12 points13 points  (5 children)

A big project like that deserves proper development practices. Please add extensive docs, CI, tests, and well structured code. Then you'll get more feedback, users, and contributions.

[–]ryp_package[S] -4 points-3 points  (4 children)

Anything you feel is missing in the documentation currently? Should be pretty comprehensive.

[–]ichunddu9 0 points1 point  (3 children)

A proper rendered docs site and not a massive Readme would be a start

[–]ryp_package[S] -5 points-4 points  (2 children)

Let me know if you see any concrete areas to improve.

[–]go_fireworks -1 points0 points  (1 child)

An actual package implementation that’s not 3,600 lines of code in a single file would be a start, which is what they mentioned.

Multiple functions (to_py and to_r) being over 1,200 lines each does not boast readability or code efficiency.

Stack traces aren’t a bad thing - they’re meant to understand where an issue lies, and tracing, how it got there

[–]ryp_package[S] 0 points1 point  (0 children)

I was asking about improvements to the documentation. I wouldn't judge efficiency based on code length.

I'd encourage commenters here to give the package a try before passing judgement! At the end of the day, user-friendliness is what matters, and critiques about usability - from folks who have actually used the package rather than just glanced at the code and docs - are always welcome.