-
Notifications
You must be signed in to change notification settings - Fork 28.5k
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
[SPARK-6661] Python type errors should print type, not object #5361
Conversation
Jenkins, test this please. |
cc @davies |
@31z4 Thanks to look into this. Personally, I like the type object instead of name of type, for example, you can got the full name of a class:
Also, we may change some |
@davies Thanks for your comments! I made changes. |
@31z4 After reading the docs again, it should be
Sorry for that. |
@davies It's OK. I may have looked into docs by myself :) |
Test build #639 has finished for PR 5361 at commit
|
@31z4 You can run |
@davies Fixed and rebased. |
Test build #641 has finished for PR 5361 at commit
|
@davies Fixed errors and rebased. |
Test build #653 has finished for PR 5361 at commit
|
@davies seems like the failures are in Scala tests. Can anyone look into that? I also had failures in Scala tests on my machine. All Python tests passed without errors though. |
Test build #654 has finished for PR 5361 at commit
|
Test build #658 has finished for PR 5361 at commit
|
@davies What should I do? Either just wait when master will be fixed or rebase to an exact commit? |
@davies I agree it's nice to get the actual object printed, rather than just the type. My problem with it was it failing to print meaningful error messages when the object did not have a default conversion to a string. (It would then print an error about the conversion, rather than about the original error.) @31z4 What if we kept printing the object (not the type) as before, but did it via a helper method used as follows:
where tryToString first tries printing the object to a string ("object blah") and, if that fails, then tries printing the type to a string ("type: objecttype")? |
@davies Oops, I misinterpreted your above comment. If we're sticking with types, then nevermind! |
@jkbradley Yes, we're sticking with types. |
@davies @jkbradley @rxin could someone look into this commit again and trigger the Jenkins test? |
Test build #677 has started for PR 5361 at commit |
It looks like this latest test run actually passed, but there was a problem in posting the success message to GitHub. I haven't been following this PR, but if other committers think it's good to go then we might want to merge it now so that it doesn't merge conflict when the Python 3 patch is merged. |
Thanks @JoshRosen! Looking forward for someone's answer. |
LGTM |
test this please |
Test build #30403 has finished for PR 5361 at commit
|
It looks like this is now merge-conflicted with master due to the Python 3 change, but I think that I should be able to resolve the conflicts myself on merge. |
Actually, it looks like the MLlib conflicts may not be all due to the Python 3 change, so do you mind fixing up these conflicts? Sorry for not preventing these conflicts by merging earlier. |
@JoshRosen I don't mind. I'll do it. |
* Replaced some related exceptions with TypeError
@JoshRosen Done. |
Jenkins, retest this please. |
Test build #30576 has finished for PR 5361 at commit
|
LGTM, so I'm going to merge this into |
Author: Elisey Zanko <[email protected]> Closes apache#5361 from 31z4/spark-6661 and squashes the following commits: 73c5d79 [Elisey Zanko] Python type errors should print type, not object
No description provided.