The package layout and internal functions, objects, etc., have changed enough to warrant a fork, and our planned changes will only make it diverge even more. We had an intermediate form of the fork named Theano-PyMC; that project attempted to preserve the Theano package name, but after a lot of old Theano bug fixes, additional features, and important refactoring, a name change was justified. The load times are one reason for making these internal changes, but the refactoring we've done up to now is just enough to start make the _real_ refactoring possible: e.g. large-scale changes to the C compilation backend and the configuration initialization process. Those changes will really fix the noticeable import delays.
Otherwise, at the user-level, Aesara can be very close to a drop-in replacement for Theano, aside from the superficial name change. The largest non-name change at the user-level is the lack of internal object exposure at package/sub-package scope (e.g. no more `[theano|aesara].*` for nearly everything in the library). This change was necessary for our refactoring efforts, since there were far too many unnecessary cross sub-package dependencies that made it very difficult to work with. Anyway, the established deprecation policy is enough to justify keeping the existing code and adding Aesara support as a new module. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/95e13769-c372-46d1-bd70-bc58ef080221n%40googlegroups.com.
