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

Add a broader "traceback hiding" mechanism #2745

Closed
nicoddemus opened this issue Sep 1, 2017 · 5 comments
Closed

Add a broader "traceback hiding" mechanism #2745

nicoddemus opened this issue Sep 1, 2017 · 5 comments
Labels
type: enhancement new feature or API change, should be merged into features branch type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@nicoddemus
Copy link
Member

The current __tracebackhide__ mechanism to hide internal code details from traceback entries is too brittle; some small refactor might start to show internal code details to users.

I propose adding a new __tracebackhideall__ mechanism which when found and set to True will strip all frames below it. This way we can add to __tracebackhideall__ at the module level of a package and any traceback from it will be hidden.

@nicoddemus nicoddemus added type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature labels Sep 1, 2017
@nicoddemus
Copy link
Member Author

xref: pytest-dev/pluggy#80

@nicoddemus nicoddemus changed the title Add new traceback hiding mechanism which is broader Add a broader traceback hiding mechanism Sep 1, 2017
@nicoddemus nicoddemus changed the title Add a broader traceback hiding mechanism Add a broader "traceback hiding" mechanism Sep 1, 2017
@RonnyPfannschmidt
Copy link
Member

duplicate of #283

@RonnyPfannschmidt
Copy link
Member

also i'm against adding more hooks and magic values, lets talk about what is internal and not via a better configuration

for consumers of sqlalchemy for example sqlalchemy may be internal (and those tracebacks can be long)

same goes for other frameworks

@RonnyPfannschmidt
Copy link
Member

also in addition - for stuff like pytest-html it may be awesome to know which traceback bit belongs to which framework

because it can just make those expandable

CC @davehunt

@nicoddemus
Copy link
Member Author

@RonnyPfannschmidt thanks for pointing it out, I have forgotten about the discussion that took place in that other thread. Closing this as duplicate.

@nicoddemus nicoddemus added type: enhancement new feature or API change, should be merged into features branch and removed type: enhancement new feature or API change, should be merged into features branch labels Sep 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement new feature or API change, should be merged into features branch type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

2 participants