%head fails with "head failed. must be real number, not str" about nbstata HOT 7 CLOSED

Thanks for reporting this. I am indeed able to reproduce it with the latest version of nbstata v0.6.4 (and the Aug 30 update of Stata 18). I'll take a look now to see if there is a relatively quick fix.

from nbstata.

I don't understand the problem yet, but I have a workaround that seems to work: changing the missing config value either in the configuration file or in a cell like:

%set missing = pandas

from nbstata.

Just verifying: this works with current v0.6.4, right?

from nbstata.

And is there a downside to using the pandas option?

from nbstata.

Yes, the workaround works with v0.6.4.

As far as a downside, I'm not aware of one. It doesn't make a visible difference in this example, and it may not ever do so. (This configuration option dates back to before I overhauled these magics to display numbers according to their Stata format, which may have made it redundant. It's that conversion to Stata format where the problem seems to lie--at this point, my best guess is that it worked with Pandas 1.4.2 but something changed by Pandas 2.1.0 that has made it not work.)

from nbstata.

Sure enough, another workaround is to add the noformat option to the %head magic. (In your example, this only removes the thousands comma from the display of "price" and "weight", but it may be a bigger deal in other cases, such as when using Stata's native date format.)

from nbstata.

Ok, I've traced it down to a change in pandas.api.types.is_string_dtype. For Pandas 1.x, pd.api.types.is_string_dtype(pd.Series([1, "."]))(pd.Series([1, "."])) returns True, but for Pandas 2.x, it returns False. I'm going to instead use not pandas.api.types.is_numeric_dtype, which is more consistent across Pandas major versions. Hoping to ship a new version shortly.

from nbstata.