1. 02 Nov, 2010 2 commits
    • Nicolas Dumazet's avatar
      Nicer way to set re-initialize classes after changing their bases. · 38e142d5
      Nicolas Dumazet authored
      1) Do not use gc.get_referrers as this is highly inefficient.
      (the returned list contains a lot of objects, some of them
      are persistent objects, some of them are not classes, etc, etc...
      But worse, "dead" objects with a zero reference count can be returned
      by this function, and this function would "ressucitate" them.
      gc.get_referrers for application code is usually a bad idea)
      
      2) Use instead a Python metaclass to track who's been subclassing
      a portal type class, and after a change on the portal type class,
      we just call the efficient PortalTypeMetaClass.getSubclassList to
      get descendants.
      
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@39751 20353a03-c40f-0410-a6d1-a30d3c3de9de
      38e142d5
    • Nicolas Dumazet's avatar
      Because we cache so much attribute lookups in local variables, · 07ecaeb3
      Nicolas Dumazet authored
      it is evil to recreate the attributes during _aq_reset.
      
      Scenario:
       * First call to aq_dynamic
       * aq_portal_type = Base.aq_portal_type
          - inner aq_dynamic business
          - causing an aq_reset call
          - Base.aq_portal_type = {}
          - [...]
          - return
      * local aq_portal_type is not anymore Base.aq_portal_type
      
      The symptoms are random, hard to reproduce loud KeyError crashes in
        hasattr(aq_portal_type[aq_key], accessor_name, None)
      that disappear on the second try.
      
      
      git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@39750 20353a03-c40f-0410-a6d1-a30d3c3de9de
      07ecaeb3
  2. 01 Nov, 2010 15 commits
  3. 31 Oct, 2010 4 commits
  4. 30 Oct, 2010 1 commit
  5. 29 Oct, 2010 18 commits