#12205: rewrite conway polynomial spkg and code in Sage library to not use ZODB
-----------------------------+----------------------------------------------
       Reporter:  was        |         Owner:  was     
           Type:  task       |        Status:  new     
       Priority:  major      |     Milestone:  sage-5.6
      Component:  databases  |    Resolution:          
       Keywords:             |   Work issues:          
Report Upstream:  N/A        |     Reviewers:          
        Authors:             |     Merged in:          
   Dependencies:             |      Stopgaps:          
-----------------------------+----------------------------------------------

Comment (by SimonKing):

 Replying to [comment:19 fbissey]:
 > I think we have to stick with the dictionary format ...

 As much as I understand, the "format" (in the sense of the "interface to
 retrieve data") does not change. That's exactly the point: If you wanted
 to inherit from dict, then you'd also have to have a `__setitem__` method
 - but we don't want to set data in an interactive session. All what we
 want is that during initialisation, data are obtained from a file, and
 then the user can retrieve these data (which is granted by the
 `__getitem__` method).

 > ... since the code in sage is littered with calls to
 !ConwayPolynomials()[p][n]

 Would that be changed by the patch? Looking at the lines
 {{{
     def __getitem__(self, key):
         try:
             return self._store[key]
         except KeyError, err:
             try:
                 if isinstance(key, (tuple, list)):
                     if len(key) == 2:
                         return self._store[key[0]][key[1]]
             except KeyError:
                 pass
             raise err
 }}}
 it seems to me that `ConwayPolynomials()[p][n]` is still a possible syntax
 (that's `return self._store[key]`), but ''in addition to the old syntax''
 we now also allow the syntax `ConwayPolynomials()[p, n]` (that's `return
 self._store[key[0]][key[1]]`).

 > and changing the storage would imply changing an enormous amount of
 code.

 By "storage", I understand the format of the data stored in the .sobj file
 containing the data base. I don't think that would be a problem, as long
 as there is a function that is able to read old data and transforms it
 into the new format.

 > I trust that your python foo is way ahead of mine. I would never have
 produced that getitem and didn't find any examples to do that with google.

 That's in
 
[http://www.diveintopython.net/object_oriented_framework/special_class_methods.html
 dive into python] or other Python introductions, or in the
 [http://docs.python.org/2/reference/datamodel.html#special-method-names
 Python documentation].

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12205#comment:22>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to