Lazy imports with deprecation

[roed314]

It's annoying when other people move something around in the Sage library and it's no longer available in the previous location to be imported. Sage currently has some mechanisms for alleviating this problem (sage.misc.superceded.deprecated_callable_import and sage.structure.sage_object.register_unpickle_override for example). This ticket adds another option: lazily import the old name so that a deprecation warning is issued whenever it is referred to.

Component: misc

Author: David Roe, Travis Scrimshaw

Branch/Commit: a484809

Reviewer: Travis Scrimshaw, Nathann Cohen

Issue created by migration from https://trac.sagemath.org/ticket/14275

[roed314]

Attachment: 14275.patch.gz

[tscrim]

Work Issues: failing doctest

[tscrim]

comment:2

Hey David,

The doctest is failing because the mismatch of the trac numbers. Also could you add a doctest with a message as well?

Thanks,

Travis

[tscrim]

Reviewer: Travis Scrimshaw

[vbraun]

comment:3

The way I see it, deprecation only makes sense for stuff that is imported into the global namespace. Anything that is not directly accessible from the command line is, by definition, an implementation detail. And once you require backwards compatibility for implementation details it basically becomes impossible to change anything. So there is no point in deprecating import locations.

[tscrim]

Commit: 108e019

[tscrim]

comment:6

This could be used to remove things from the global namespace but the class itself doesn't change.

---

New commits:

108e019

Adds a deprecation option to lazy_import.

[tscrim]

Branch: u/tscrim/14275

[tscrim]

Changed work issues from failing doctest to none

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

a484809

Doctest fixes.

[sagetrac-git]

Changed commit from 108e019 to a484809

[nathanncohen]

comment:9

Comment from the sage-combinat thread :

the way it is implemented you add a "deprecation"
feature to lazy import. But lazy imports can be used a lot, so
wouldn't it be better to instead add a "lazy" feature to
"deprecation_function_alias" ?

Nathann

[tscrim]

comment:10

No, because then we'd have to import deprecated_function_alias (which doesn't currently accept a message too) and import the original object just to do something like

x = deprecation_function_alias(14275, x)

Otherwise we completely change the syntax and functionality to include lazy_import. Both of which are asinine.

[nathanncohen]

comment:11

Ahahaahha. Well, for as long as you know that the two reasons you gave me are bad reasons and can be easily avoided, all is fine. It is not so bad.

Good to go !

Nathann

[nathanncohen]

Changed reviewer from Travis Scrimshaw to Travis Scrimshaw, Nathann Cohen

[nathanncohen]

Changed author from David Roe to David Roe, Travis Scrimshaw

[tscrim]

comment:12

Thanks Nathann.

[vbraun]

Changed branch from u/tscrim/14275 to a484809