-
Notifications
You must be signed in to change notification settings - Fork 18
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
Fixes #290: pyPrint accepts any filelike, with sys.stdout fallback #90
Comments
Comment by trotterdylan The types_test failure is because types.py defines ModuleType as type(sys) and types_test checks that it's the same type as go.grumpy.ModuleType. sys is now a different kind of object. I would remove that line from types.py and add The other issue is a transient failure due to a race condition in TestRunMain. I can trigger it reasonably consistently as follows:
I think this is similar to google#282. This is not due to your change. Just restart the build if you encounter that again. |
Comment by alanjds OSX: Thanks. Will take a look on Linux: Good to know. However, how can I restart the build on Travis? Last time I had sent a pointless commit to trigger it, but this adds noise to the history. |
Comment by alanjds I had hit another strange error here, on itertools_test.py:
Bisected and found its root on f745cdb, but it makes no sense. As this PR will not be merged until __getattr__ is working, will leave it as is. This seems as a symptom of another undiscovered bug on the module/types stuff. |
google#304 opened on May 1, 2017 by @alanjds
Gets sys.stdout from SysmoduleDict['stdout'], that exists and could be replaced (after #70 got merged)
pyPrint allows any filelike *Object to be printed to.
TBD: Factor out the method invocation logic to some
func (o *Object) Invoke(f *Frame, method *Str)
The text was updated successfully, but these errors were encountered: