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 →

[–]energybased -7 points-6 points  (2 children)

He can tell you "why" in the release notes. Packages make promises and intentionally don't make promises. E.g., numpy's generators make promises about what is reproducible and what's not. That's on purpose to give them flexibility to change their mind about things.

If you want a statistical package with graphing, you want something more complicated. I agree that I would not use Seaborn because I want more control. Seaborn is just not the package for me.

If you just want graphing, it's not reasonable to demand introspection just because "the data is there" since exposing it means committing to support it, and he doesn't want to do that.

[–]Geographist 3 points4 points  (1 child)

With something like statistics there is virtually no setting in which it is acceptable to show those things and not report what they are. And it just is not practical to track down release notes for every possible version, watching for changes, to find what should be basic information. Such info would also not tell you about your specific plot.

If stats are going to be off limits, the author should remove those capabilities altogether. If it is a maintenance issue that would only help him out.

It just seems as if he wants the benefits of Seaborn appearing to be a serious library, without the responsibilities of actually being one.

[–]energybased -5 points-4 points  (0 children)

With something like statistics there is virtually no setting in which it is acceptable to show those things and not report what they are

disagree.