Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate _populate_coercion_lists_(element_constructor=...) #24363

Closed
jdemeyer opened this issue Dec 10, 2017 · 14 comments
Closed

Deprecate _populate_coercion_lists_(element_constructor=...) #24363

jdemeyer opened this issue Dec 10, 2017 · 14 comments

Comments

@jdemeyer
Copy link

As an effort to reduce the number of entry points to the "element constructor" (see #23880), get rid of _populate_coercion_lists_(element_constructor=...). Instead, set an Element attribute or implement an _element_constructor_ method.

Unpickling still calls _populate_coercion_lists_(element_constructor=...) and we are not fixing this for now.

CC: @tscrim

Component: coercion

Author: Jeroen Demeyer

Branch/Commit: d7b390b

Reviewer: Travis Scrimshaw

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

@jdemeyer jdemeyer added this to the sage-8.2 milestone Dec 10, 2017
@jdemeyer

This comment has been minimized.

@jdemeyer
Copy link
Author

Author: Jeroen Demeyer

@jdemeyer

This comment has been minimized.

@jdemeyer
Copy link
Author

@jdemeyer
Copy link
Author

Commit: d7b390b

@jdemeyer

This comment has been minimized.

@jdemeyer
Copy link
Author

New commits:

d7b390bDeprecate _populate_coercion_lists_(element_constructor=...)

@tscrim
Copy link
Collaborator

tscrim commented Dec 15, 2017

comment:5

Can you explain why in some cases you did:

_element_constructor_ = integer.Integer

and for others you used Element? Is it for speed reasons (in particular, avoiding a level of indirection), coupled with the fact the elements are extension classes?

Otherwise everything else LGTM (although I would like to see, e.g., BrandtModuleElement._add_ use type(self) instead of BrandtModuleElement as forward-proofing, but I only noticed that because the code simply moved locations and is unrelated to this ticket).

@jdemeyer
Copy link
Author

comment:6

Replying to @tscrim:

Can you explain why in some cases you did:

_element_constructor_ = integer.Integer

and for others you used Element?

The reason is that most element classes take the parent as argument. So the default _element_constructor_ method passes the parent to the element class. For ZZ, the parent is constant, so it is not passed in the Integer constructor. So I need a custom _element_constructor_ "method".

Here it is not actually a method but a class used as callable object. I could wrap it in a method, but it works this way so I didn't do that.

@jdemeyer
Copy link
Author

comment:7

Replying to @tscrim:

I only noticed that because the code simply moved locations and is unrelated to this ticket).

Indeed. If you do

class BrandtModule_class(AmbientHeckeModule):
    Element = BrandtModuleElement

you need to define BrandtModuleElement before BrandtModule_class.

@tscrim
Copy link
Collaborator

tscrim commented Dec 15, 2017

comment:8

Replying to @jdemeyer:

Replying to @tscrim:

Can you explain why in some cases you did:

_element_constructor_ = integer.Integer

and for others you used Element?

The reason is that most element classes take the parent as argument. So the default _element_constructor_ method passes the parent to the element class. For ZZ, the parent is constant, so it is not passed in the Integer constructor. So I need a custom _element_constructor_ "method".

Ah, I see. Makes sense. Thanks.

Here it is not actually a method but a class used as callable object. I could wrap it in a method, but it works this way so I didn't do that.

I think what you did is the most sensible way (at least that I can see).

@tscrim
Copy link
Collaborator

tscrim commented Dec 15, 2017

Reviewer: Travis Scrimshaw

@tscrim
Copy link
Collaborator

tscrim commented Dec 15, 2017

comment:9

Replying to @jdemeyer:

Replying to @tscrim:

I only noticed that because the code simply moved locations and is unrelated to this ticket).

Indeed. If you do

class BrandtModule_class(AmbientHeckeModule):
    Element = BrandtModuleElement

you need to define BrandtModuleElement before BrandtModule_class.

Not strictly speaking, as you can do BrandtModule_class.Element = BrandtModuleElement later on down at the module-level, but that is quite ugly IMO.

@vbraun
Copy link
Member

vbraun commented Dec 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants