-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
DataFrame.to_string truncates long strings #9784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think it picks that option up from |
yes, that solved it, thx. I guess it should not pick that up for a to_string() operation, as that is not |
Is this issue resolved? I am getting this same issue on 0.20.3 |
There was no changes, just further documentation. |
Is the solution to modify the display settings? That seems pretty unsatisfactory. |
@jreback : Thoughts? |
i would argue that the "to_string" method should be independent from a display setting for real-time analysis. A string object is not necessarily being used for display purposes. |
In my present case, I am accessing a Redshift admin table to get a table DDL. The data frame has just that column/DDL, but I want to modify it in memory using a string operation -- split(';'). I think the to_string operation should definitely not carryover any display settings. |
Or, at least, to have a parameter we can toggle. That could work. |
Yes, I don't think the documentation addition really solved this issue. The |
So for me, PR welcome for this! |
#1852 is probably a duplicate of this |
I can hardly see how the coupling of the display limit with any other processing helps in solving this benign scenario. And not really how padding the strings which I notice takes place as well, helps, outside the display scenario. If there's too much history behind it, would you recommend using the plain csv package of python, for reading strings without modifying them? Here's a naive code sample, if it helps anyone ―
This seems to avoid the truncation (but not the padding, which hurts a little with right-to-left text, as it pads as if the text is left-to-right, which kind of skews the semantics of the text more in the case of right-to-left text) |
two days debugging to find out this was the issue. i'm sad... |
see also #24841 for fix in to_html |
This was incredibly frustrating to debug. I was executing the code below and getting "..." in my output. I assumed it was just printing the "..." to the console, not in the dataframe! While I'm sure this isn't a
If this were my first experience with Pandas, I'd promptly throw it in the trash. Note: I love Pandas and thank you everyone for amazing work you do! I just wanted to share my experience. |
With Pandas 0.25.0, setting display.max_colwidth to a large number stops the truncation but when trying to left justify columns with df.to_string(justify='left'), that same display setting somehow pads columns on the left so they are not left aligned. Is there any present way to prevent truncation and get left justified string columns when output to a terminal? I know a pull request is in process but I would like to do this now. Thanks. |
May I ask what the use case of having the to_string method dependent on the display.max_colwidth option? I can't seem to understand why one would ever ask for a DataFrame row as a string with truncated column values |
@yamen321 I think it's agreed that to_string shouldn't truncate. Are you interested in working on it? |
Hi! I jumped in on the "good first issue" label and put up a PR to solve this. Feedback very welcome. |
Thanks a lot for taking the initiative on this @lshepard! |
Hey I have a
I want to extract the filenames from the url so
I just want the file
If the filename is long string my output looks like
though using dataframe would be much faster than
Any work around here, instead of this?
|
I am calling to_string() without any parameters and it beautifully fixed-formatted my dataframe apart from my very wide filename column, that is being truncated with "...". How can I avoid that?
I tried calling it like this, but to no avail (same output):
Version: 0.16 with Python 3.4
The text was updated successfully, but these errors were encountered: