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

enhancement for operator 'assert' #62842

Closed
WitcherGeralt mannequin opened this issue Aug 3, 2013 · 10 comments
Closed

enhancement for operator 'assert' #62842

WitcherGeralt mannequin opened this issue Aug 3, 2013 · 10 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@WitcherGeralt
Copy link
Mannequin

WitcherGeralt mannequin commented Aug 3, 2013

BPO 18642
Nosy @mdickinson, @bitdancer

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-08-04.07:19:00.757>
created_at = <Date 2013-08-03.11:53:07.686>
labels = ['interpreter-core', 'type-feature']
title = "enhancement for operator 'assert'"
updated_at = <Date 2013-08-04.07:19:00.755>
user = 'https://bugs.python.org/WitcherGeralt'

bugs.python.org fields:

activity = <Date 2013-08-04.07:19:00.755>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2013-08-04.07:19:00.757>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2013-08-03.11:53:07.686>
creator = 'WitcherGeralt'
dependencies = []
files = []
hgrepos = []
issue_num = 18642
keywords = []
message_count = 10.0
messages = ['194250', '194251', '194257', '194259', '194263', '194288', '194290', '194292', '194294', '194326']
nosy_count = 4.0
nosy_names = ['mark.dickinson', 'r.david.murray', 'WitcherGeralt', 'mrDoctorWho0..']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue18642'
versions = ['Python 3.4']

@WitcherGeralt
Copy link
Mannequin Author

WitcherGeralt mannequin commented Aug 3, 2013

It would be pretty good, if 'assert' could raise specified exception, like that:

>> data = None
>> assert isinstance(data, basestring), TypeError("'data' must be a string")

<s>AssertionError</s>TypeError: 'data' must be a string

@WitcherGeralt WitcherGeralt mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Aug 3, 2013
@mdickinson
Copy link
Member

What's wrong with:

if not isinstance(data, basestring):
    raise TypeError(...)

?

In any case, you appear to be wanting to use assert to check user input. That's not its intended use; instead, it's there for making debugging assertions. Bear in mind that when running in optimized mode (with python -O), Python won't execute those asserts at all. (See http://docs.python.org/3.4/reference/simple_stmts.html#the-assert-statement for more.)

I think this should be rejected.

@WitcherGeralt
Copy link
Mannequin Author

WitcherGeralt mannequin commented Aug 3, 2013

Mark Dickinson, and I just think it might be useful in debug. PYO is another story.

@mdickinson
Copy link
Member

Ah, so I think I don't understand the proposal. In your original message, is it your intention that the assert raises TypeError, or that it raises AssertionError?

Again: what's the benefit over existing solutions? Either:

    if not isinstance(data, basestring):
        raise TypeError("Bad user!  You gave me the wrong type")

or

assert isinstance(data, basestring), "data should be a string at this point"

?

@bitdancer
Copy link
Member

I think it would be confusing for assert to raise anything other than an AssertionError, so I also think this should be rejected.

It might be interesting for there to be a way to call unittest's assert methods in a debug context (that is, without having to have a test case around), but that is a very non-trivial (and probably impractical) thought :)

@WitcherGeralt
Copy link
Mannequin Author

WitcherGeralt mannequin commented Aug 3, 2013

Mark Dickinson, #1 if dedug (and type check, respectively, as in this example, and 'raise') isn't needed we just need pyo

> Python won't execute those asserts at all
that is convenient.

if not isinstance(data, basestring):
    raise TypeError(...)

R. David Murray, yes, maybe confusing, but I can imagine many ways when it is very convenient.

@WitcherGeralt
Copy link
Mannequin Author

WitcherGeralt mannequin commented Aug 3, 2013

Mark Dickinson, sorry, didn't answer the first questiuon.

> In your original message, is it your intention that the assert raises TypeError, or that it raises AssertionError?

I suggest to add the ability to raise relevant (for specific part of code) exception on checking assertion.

@mrDoctorWho0
Copy link
Mannequin

mrDoctorWho0 mannequin commented Aug 3, 2013

Assert with this feature will make code simplest. Simplification isn't python way? Why don't add it in python? It's must be really useful. Sometimes its necessary, when need to catch specified exception. Its easier to search errors by type, not by error body

@bitdancer
Copy link
Member

If your code is catching an exception generated by an assert statement, your code is using assert incorrectly. There is never any reason, as far as I can see, to catch an assert outside of a testing framework, and in a testing framework you definitely want to be catching an AssertionError when you are trying to catch an assert failing. Making it some other error would just confuse the testing framework.

@mdickinson
Copy link
Member

Okay, I'm closing this for now. Al Korgun and mrDoctorWho0 .: if you think this idea deserves wider discussion, you should feel free to bring it up again on the python-ideas mailing list; that's a better forum to discuss these sorts of language changes anyway (too few developers will look at any particular bug on the bug tracker; many more read python-ideas). It seems unlikely to me that the idea would receive widespread acceptance, but I may well be wrong.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants