<div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks for starting this discussion. I think each of the points need an independent discussion. In general I think the solution would be to deprecate things in pandas.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For the inplace keyword, there is consensus to deprecate it. There was even before pandas 1.0 and plans to remove it everywhere before it, and we almost removed it for pandas 2.0 (not finally happening), but there are still few details to discuss. I guess a linter can help before we start raising the FutureWarnings.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For isna/isnull, the initial plan and obvious solution was to also deprecate isnull, but it was <a href="https://github.com/pandas-dev/pandas/pull/16972#issuecomment-317216086">decided</a> it was too common. Seems like deprecating it is a better option that a linter. But I guess if the linter is popular enough could help. I'd personally just deprecate things we don't want users to use (instead of encouraging a linter), but if there is no consensus to deprecate, maybe there will be in the future and the linter can help. Some things are trickier, but I guess in general we could end up deprecating things like Series.values in favor of .array or .to_numpy()...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Personally -1 on `import pandas as pd`. If we had to rewrite things I guess the numpy module would be simply named np, so no aliasing is needed. And the pandas module namespace is much smaller and not used so frequently, and shorting it to pd has almost no impact in code verbosity. I never alias the pandas module name, and while consistency across projects can be nice, seems odd to have a linter to recommend something that is more a tradition than a good practice. At least that's my opinion.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 2, 2023 at 4:09 PM Roman Yurchak <<a href="mailto:rth.yurchak@gmail.com">rth.yurchak@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>There was interesting work done in <a href="https://github.com/deppen8/pandas-vet" target="_blank">https://github.com/deppen8/pandas-vet</a> for enforcing automated checks on pandas code.<br><br>I was wondering if the core teams had some opinions on the enforced rules and could comment to what extent there is a consensus on those, whether they are consistent with what's recommended in the pandas docs. Particularly on things, like pivot_table vs unstack, .array vs .values, and melt vs stack.<br><br>Currently working on a largish legacy code with lots of pandas code, so IMO something like pyupgrade for pandas could really be great. Also now that pandas-vet is implemented in ruff, I feel it has the potential to become mainstream in a few years. Just checking whether there is some consensus on what could / should be enforced for pandas linting. <br><br>For the rule "'inplace = True' should be avoided; it has inconsistent behavior": if there is an issue,  this could be fixed in some future major release, right ?<br><br>Thanks,<br><br>Roman </div>
_______________________________________________<br>
Pandas-dev mailing list<br>
<a href="mailto:Pandas-dev@python.org" target="_blank">Pandas-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/pandas-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/pandas-dev</a><br>
</blockquote></div>