homepage

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

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.

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

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"
?

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 :)

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(...)
- here we need additionally check debug variable, use wrapper or something.
#2 'assert' is a good breakpoint (sorry, bad english. not sure if this is what I wanted to say) on its own. And to orientate on check & 'raise' we have to mark it somehow.
#3 Well, the code is shorter, obviously.
R. David Murray, yes, maybe confusing, but I can imagine many ways when it is very convenient.

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.

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

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.

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.