Can we use property decorators to resolve this for standard Node properties?
-Bill On Mon, Mar 2, 2015 at 8:40 AM, Kenny, Jason L <[email protected]> wrote: > Hi dirk, > > I need to give this a run. As I am one of the people that would be in a > dangerous area :-) > > My first thought however would be this: > > 1) did we add a __dict__ to the __slots__ ? if not can we, this would > probally fix 99% of the issues I would have in Parts > 2) stuff like t.abspath -> t.get_abspath(), can the t.abspath be a > property that calls t.get_abspath()? > > This seems like this would deal with most of the concerns people might > have. I understand that there might be good reason not to do this. I > haven't looked in detail yet myself. > > Just some thoughts. > > Jason > > > -----Original Message----- > From: Scons-dev [mailto:[email protected]] On Behalf Of Dirk > Bächle > Sent: Saturday, February 28, 2015 6:03 AM > To: SCons users mailing list > Cc: SCons developer list > Subject: [Scons-dev] Announcement: Core changes for v2.4 ahead, Switching > the Node class to using slots... > > Hello there, > > as has been pre-announced at > > https://pairlist4.pair.net/pipermail/scons-users/2014-July/002734.html > > and > > > https://pairlist2.pair.net/pipermail/scons-dev/2014-December/002107.html > > we're still planning to switch the Node class to using "slots" in the core > sources, mainly for reducing the overall memory consumption by up to 35% in > large build projects. > > We have now pushed a new branch named "switch_to_slots" to the main SCons > repo, and ran it against our test suite in Buildbot ( > http://buildbot.scons.org/waterfall ). So far, the implementation looks > stable and for the normal user there shouldn't be any danger of > scripts/builds breaking after an update to the new release 2.4 (coming > probably in a month or so). > > However, if you write and maintain your own extensions, where you > regularly reach into the bowels of SCons to extract internal data or to > override methods (monkey-patching), there is a chance that you'll get > bitten by the changes as described in the appendix below. > > We invite any interested user/developer to try out the current "slots" > branch, by cloning > > hg clone http://bitbucket.org/scons/scons -r switch_to_slots > > to a local folder (not your standard SCons repo!), and starting it via the > "bootstrap.py" script: > > python ~/try_out_folder/scons/bootstrap.py > > Please report back any errors or inconveniences that you find, such that > we can work on a solution together. > If you have further questions, better ask them now. We won't look back > after merging this. ;) > > > Best regards, > > Dirk > > > Appendix: Short list of changes to the Node* classes > ==================================================== > > - Introduction of decorators for memoizer debugging/counting (we can't use > metaclasses anymore). > - Adding interface for accessing node attributes that may get initialized > lazily: > t.abspath -> t.get_abspath() > t.labspath -> t.get_labspath() > t.tpath -> t.get_tpath() > t.path_elements -> t.get_path_elements() > t.path -> t.get_internal_path() > > - Methods like t.exists(), t.rexists() and t.get_contents() can't be > re-assigned directly anymore. They'll be realized via function maps > internally ( {int : func} ). > > - NodeInfo and BuildInfo will also get switched to __slots__, and get a > new internal version number (1.0 -> 2.0). This means that after the switch > *all* targets are regarded to be out-of-date on the first build. > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
