A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-January/051141.html below:

[Python-Dev] Exceptions *must*? be old-style classes?

[Python-Dev] Exceptions *must*? be old-style classes? [Python-Dev] Exceptions *must*? be old-style classes?Guido van Rossum gvanrossum at gmail.com
Mon Jan 17 16:27:33 CET 2005
[Armin]
> For reference, PyPy doesn't have old-style classes at all so far, so we had to
> come up with something about exceptions.  After some feedback from python-dev
> it appears that the following scheme works reasonably well.  Actually it's
> surprizing how little problems we actually encountered by removing the
> old-/new-style distinction (particularly when compared with the extremely
> obscure workarounds we had to go through in PyPy itself, e.g. precisely
> because we wanted exceptions that are member of some (new-style) class
> hierarchy).
> 
> Because a bit of Python code tells more than long and verbose explanations,
> here it is:
> 
> def app_normalize_exception(etype, value, tb):
[...]
>     elif type(etype) is str:
>         # XXX warn -- deprecated
>         if value is not None and type(value) is not str:
>             raise TypeError("string exceptions can only have a string value")

That is stricter than classic Python though -- it allows the value to
be anything (and you get the value back unadorned in the except 's',
x: clause).

[Michael]
> It would still be worth doing, IMHO.

Then let's do it. Care to resurrect your patch? (And yes, classic
classes should also be allowed for b/w compatibility.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

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