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

Add classcall setter in ClasscallMetaclass #12894

Closed
nthiery opened this issue May 1, 2012 · 10 comments
Closed

Add classcall setter in ClasscallMetaclass #12894

nthiery opened this issue May 1, 2012 · 10 comments

Comments

@nthiery
Copy link
Contributor

nthiery commented May 1, 2012

The optimization of ClasscallMetaclass in #12808 prevents dynamically changing the __classcall__ method of a class. This followup adds an appropriate setter to enable this feature.

CC: @hivert @simon-king-jena

Component: misc

Keywords: classcall UniqueRepresentation

Author: Nicolas M. Thiéry

Reviewer: Florent Hivert

Merged: sage-5.10.beta1

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

@nthiery nthiery added this to the sage-5.10 milestone May 1, 2012
@simon-king-jena
Copy link
Member

comment:1

Is it ready for review, yet?

@nthiery
Copy link
Contributor Author

nthiery commented May 3, 2012

comment:2

Replying to @simon-king-jena:

Is it ready for review, yet?

I was just hesitant whether we wanted to aim (in the long run) for one setter for each special method (set_classcall, set_classget, ...), or a single setter for all of them (and in that case what name we want for this setter).

Other than that, yes, needs review!

@hivert
Copy link

hivert commented May 5, 2012

comment:3

Hi Nicolas,

Thanks for this one. I've a request: You should describe the input of
_set_classcall__ saying that the function must accept the class itself
at first argument. I'll try to post a review patch.

I'm also w little worried about the interface: Alternatively we could either

  • make the attribute classcall public (maybe by renaming it with
    underscores (I mistyped underscare at first ;-)).

  • or use a property to have a real setter allowing to a nicer syntax. I'm
    pretty sure Cython allows ot too.

Florent

@hivert
Copy link

hivert commented Jan 30, 2013

comment:4

Replying to @hivert:

I'm also w little worried about the interface: Alternatively we could either

  • make the attribute classcall public (maybe by renaming it with
    underscores (I mistyped underscare at first ;-)).

  • or use a property to have a real setter allowing to a nicer syntax. I'm
    pretty sure Cython allows ot too.

Nicolas: any idea about that ?

Florent

@nthiery
Copy link
Contributor Author

nthiery commented Jan 30, 2013

comment:5

Replying to @hivert:

Replying to @hivert:

I'm also w little worried about the interface: Alternatively we could either

  • make the attribute classcall public (maybe by renaming it with
    underscores (I mistyped underscare at first ;-)).

  • or use a property to have a real setter allowing to a nicer syntax. I'm
    pretty sure Cython allows ot too.

Nicolas: any idea about that ?

Oops, I let that ticket die, whereas I need it soon in Sage for the
functorial constructions. Thanks for the reminder!

If the property approach can be made to work, it sounds like the one
that encapsulates best the details of the caching of the resolution of
classcall. So I vote for it. Does it look feasible?

Cheers,
Nicolas

@hivert
Copy link

hivert commented Jan 30, 2013

comment:6

Replying to @nthiery:

Oops, I let that ticket die, whereas I need it soon in Sage for the
functorial constructions. Thanks for the reminder!

If the property approach can be made to work, it sounds like the one
that encapsulates best the details of the caching of the resolution of
classcall. So I vote for it. Does it look feasible?

See: http://docs.cython.org/src/userguide/extension_types.html#properties

We just need to check that we have a sufficiently recent Cython in Sage and
that this doesn't induce some unacceptable overhead.

Cheers,

Florent

@nthiery
Copy link
Contributor Author

nthiery commented Mar 26, 2013

comment:7

Replying to @hivert:

Replying to @nthiery:

Oops, I let that ticket die, whereas I need it soon in Sage for the
functorial constructions. Thanks for the reminder!

If the property approach can be made to work, it sounds like the one
that encapsulates best the details of the caching of the resolution of
classcall. So I vote for it. Does it look feasible?

See: http://docs.cython.org/src/userguide/extension_types.html#properties

We just need to check that we have a sufficiently recent Cython in Sage and
that this doesn't induce some unacceptable overhead.

I just looked at this, and it seems we can't make this approach work:
Indeed, even if we define __classcall__ as a property in
ClasscallMetaclass, any class C which will implement its own
__classcall__ will overwrite the property. But then,
C.classcall = ... won't work ...

So at this point I'd go with just the _set_classcall approach, unless you see a way out.

@nthiery
Copy link
Contributor Author

nthiery commented Mar 26, 2013

comment:8

Updated patch which uses cls rather than self for the first argument of _set_classcall. The interface is not perfect, but that's an internal method and we can change this later on if we get a better idea.

@hivert
Copy link

hivert commented Apr 25, 2013

comment:9

Attachment: trac_12894-classcall_setter-nt.patch.gz

@jdemeyer
Copy link

Merged: sage-5.10.beta1

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

5 participants