On Mon, Jun 09, 2003, Michael Hudson wrote: > Aahz <aahz@pythoncraft.com> writes: >> On Mon, Jun 09, 2003, Steven Taschuk wrote: >>> Quoth Brett C.: >>>> >>>> I am +1 on deprecating string exceptions for Python 3. >>> >>> PEP 317 actually proposes formally deprecating them in 2.4, and >>> eliminating them entirely in 3.0. Are you +1 on that? >> >> Given how deeply embedded string exceptions are in Python, > > How deep is that? 'python -X' went away, causing no pain at all as > far as I could tell. Well, I was still casually using string exceptions up until about a year ago, and I think I'm not the only one. There's probably lots of pre-2.0 code still running in the wild with string exceptions. >> I believe that we cannot afford to issue a DeprecationWarning until >> we start doing the same for integer division. > > $ python -E -Wall > Python 2.3b1+ (#1, May 6 2003, 18:00:11) > [GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> raise "hello" > __main__:1: PendingDeprecationWarning: raising a string exception is deprecated > Traceback (most recent call last): > File "<stdin>", line 1, in ? > hello > > We don't seem to do that for integer division yet. Correct. Note that I said "Deprecation", not "PendingDeprecation". If we're just going to use PendingDeprecation, I'm fine with that in 2.4. Seems to me that both integers and string exceptions require line-by-line analysis to correct, and I think it's unfair to shove people to do that work twice. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4