Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#4301 closed defect (invalid)

[with patch, needs work] lookup generic methods on category

Reported by: robertwb Owned by: robertwb
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: coercion Keywords:
Cc: mhansen Merged in:
Authors: Reviewers:
Report Upstream: Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

No caching is done yet, but it shouldn't be too hard to add at some point.

Attachments (1)

4301-cat-lookup.patch (3.0 KB) - added by robertwb 11 years ago.

Download all attachments as: .zip

Change History (8)

Changed 11 years ago by robertwb

comment:1 Changed 11 years ago by craigcitro

  • Summary changed from [with patch, needs review] lookup generic methods on category to [with patch, needs doctests] lookup generic methods on category

So this patch looks good -- I believe that the code does what it claims to.

However, there are no doctests.

So if you say "there are no categories that implement anything like this yet," I believe you -- but let's add one, and put it in the docstring, so that we can use this as an example.

comment:2 Changed 10 years ago by mabshoff

  • Summary changed from [with patch, needs doctests] lookup generic methods on category to [with patch, needs work] lookup generic methods on category

comment:4 Changed 10 years ago by mhansen

  • Milestone changed from sage-4.2 to sage-duplicate/invalid/wontfix
  • Resolution set to invalid
  • Status changed from needs_work to closed

I'm going to go ahead and close this as invalid since we decided on another approach for handling these generic method lookups.

comment:5 Changed 10 years ago by robertwb

The other method doesn't work for Cython elements or parents.

comment:6 Changed 10 years ago by mhansen

Hmm... I must have been confused. I thought we had worked that out in the categories code.

Is this patch still current / relevant?

comment:7 Changed 10 years ago by robertwb

The combinat way of doing things was to make all elements and parents into dynamically generated classes with one half coming from their category and the other half from their implementation. Of course, this makes them Python types, which would be an unacceptable speed regression for, e.g. Integer, so we need some manual lookup in that case.

What we haven't done is figured out how the these two different approaches would interact, and this should be worked out before applying (some variation of) the above patch.

Note: See TracTickets for help on using tickets.