Skip to content
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

AttributeError: '_io.FileIO' object has no attribute 'errors' #555

Closed
pytestbot opened this issue Aug 1, 2014 · 7 comments
Closed

AttributeError: '_io.FileIO' object has no attribute 'errors' #555

pytestbot opened this issue Aug 1, 2014 · 7 comments
Labels
type: bug problem that needs to be addressed

Comments

@pytestbot
Copy link
Contributor

Originally reported by: Jason R. Coombs (BitBucket: jaraco, GitHub: jaraco)


New in pytest 2.6.0, many setuptools tests are failing thus: https://travis-ci.org/jaraco/setuptools/jobs/31453603

In particular, the error occurs with this traceback:

c:\python\lib\distutils\log.py:44: in info
    self._log(INFO, msg, args)
c:\python\lib\distutils\log.py:30: in _log
    if stream.errors == 'strict':
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <_pytest.capture.EncodedFile object at 0x0000000005C87128>
name = 'errors'

    def __getattr__(self, name):
>       return getattr(self.buffer, name)
E       AttributeError: '_io.FileIO' object has no attribute 'errors'

c:\python\lib\site-packages\pytest-2.6.0-py3.4.egg\_pytest\capture.py:242: AttributeError

Using Python 2.x or pytest 2.5.x works around the issue.


@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


The capturing stream is a kind of a "pseudo" stream. The error probably goes away if you disable output capturing with -s. I guess we need to work harder and maybe provide an "errors" attribute on the capture-stream.

@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


i have a fix which just sets "errors='strict'" on the EncodedFile internal stream. Could you try it out? you can install via "pip install --pre -i https://devpi.net/hpk/dev/ pytest" (should give you 2.6.1.dev3). Want to release pytest-2.6.1 anytime now so feedback very welcome.

@pytestbot
Copy link
Contributor Author

Original comment by Jason R. Coombs (BitBucket: jaraco, GitHub: jaraco):


That fixed it. Thanks!

@pytestbot
Copy link
Contributor Author

Original comment by Jason R. Coombs (BitBucket: jaraco, GitHub: jaraco):


I spoke too soon...

@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


the links you had don't seem to use 2.6.1.dev3 but rather 2.6.0 -- but could you elaborate in any case?

@pytestbot
Copy link
Contributor Author

Original comment by Jason R. Coombs (BitBucket: jaraco, GitHub: jaraco):


I failed to include --upgrade in the installation of pytest, so the dependency was satisfied and didn't get the patch.

It's definitely fixed now. (sorry for the noise)

@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


fix issue555: just add "errors" attribute to internal Capture stream.

@pytestbot pytestbot added the type: bug problem that needs to be addressed label Jun 15, 2015
bluetech added a commit to bluetech/pytest that referenced this issue Mar 7, 2020
I tried to understand what the `safe_text_dupfile()` function and
`EncodedFile` class do. Outside tests, `EncodedFile` is only used by
`safe_text_dupfile`, and `safe_text_dupfile` is only used by
`FDCaptureBinary.__init__()`. I then started to eliminate always-true
conditions based on the single call site, and in the end nothing was
left.

The old code had some workarounds:

- Ensure `errors` property is set: pytest-dev#555.
  It is set now, although now it will return `replace`, which is the
  actual method used also before, instead of `strict`. AFAIU, the issue
  just wanted it to be set to something, not `strict` specifically.

- Infinite recursion trying to pickle `EncodedFile` (f7282b8).
  Not sure, I don't think this object should be pickle-able at all (and
  it isn't...).

- A bug in `logging.Handler.__repr__` with int `file.name`.
  pytest-dev#2555
  Was fixed in Python>=3.7.4: https://bugs.python.org/issue36015.
  TODO: This workaround is probably still needed?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug problem that needs to be addressed
Projects
None yet
Development

No branches or pull requests

1 participant