Opened 7 years ago

Last modified 7 years ago

#6293 enhancement new

Deprecate support for representing exception types using strings in Failure.check and Failure.trap

Reported by: Alex Gaynor Owned by: Alex Gaynor
Priority: normal Milestone:
Component: core Keywords:
Cc: Branch:

Description (last modified by Jean-Paul Calderone)

Failure.check and Failure.trap accept strings like "exceptions.ValueError" to mean the same thing as is meant by passing the exception type named by that string (iow ValueError in this case).

This may be dubious functionality. It was probably motivated by use-cases like twisted.spread where exception type names are passed over the network and turning these names back into exception type objects is potentially dangerous (and it is easier to be confident in the safety of code which simply does not do it).

That said, twisted.spread appears not to actually use this functionality itself, but perhaps applications based on twisted.spread do. If there aren't many such applications, getting rid of the functionality may be fine.

However, if there are, then we should probably consider keeping the functionality instead - either as is (iow, mark this ticket as invalid), or at least under a new (explicitly and only name-based) API.

Attachments (1)

failure-string-exc.diff (2.1 KB) - added by Alex Gaynor 7 years ago.
Patch, missing tests and docs.

Download all attachments as: .zip

Change History (4)

Changed 7 years ago by Alex Gaynor

Attachment: failure-string-exc.diff added

Patch, missing tests and docs.

comment:1 Changed 7 years ago by Jean-Paul Calderone

Owner: set to Alex Gaynor

It's already impossible to create a Failure with a string exception. The feature this patch removes is related to conveying information about failures over the network. That's a completely separate thing from supporting strings themselves as exceptions.

I think this ticket needs to be more clearly defined in its goals.

comment:2 Changed 7 years ago by Alex Gaynor

exarkun: the goal of this patch was to simplify the check method, which is currently complex, slow, and a little bizarre (e.g. exception types are compared by the strings of their modules, rather than in a normal pythonic fashion). It's unclear to me why Failure needs to support information about exceptions over a network, it's documenting as wrapping a python exception in a more asynchronous-friendly manner, not providing for remote exceptions.

comment:3 Changed 7 years ago by Jean-Paul Calderone

Description: modified (diff)
Summary: Deprecate string exceptions in FailureDeprecate support for representing exception types using strings in Failure.check and Failure.trap

I adjusted the summary and description to try to describe the issue more accurately. Unfortunately I had to leave an open question in the description, because I don't really know who is using this API and whether such uses could easily be changed. Notice that the ticket really has nothing to do with the removal of string exceptions starting in Python 2.6.

Note: See TracTickets for help on using tickets.