[Scons-dev] Announcement: Core changes for v2.4 ahead, Switching the Node class to using slots...

[alexandre at feblot.fr]

Hum,

in fact, 1 and 3 and also the idea to checkin Scons 2.3 in our current code (as well as all maintenance branches) are equivalent, and painful: We have many maintenance branches, and hundreds of tags that potentially may have to be checked out again and recompiled.

2 seems to be the only actual solution in order to keep all existing code working.

However, what would you think about such implementation which keeps compatible with current code:

- rename private attributes. example: abspath -> private_abspath
- for new code, use new interface. example: get_abspath() { return self.private_abspath }
- for old code, allow using the old private attribute thanks to __getattr__():


class Node:

    __slots__ = ('private_abspath')

    def __init__(self):
        self.private_abspath = None
    
    def get_abspath(self):
        self.private_abspath = "/a/path" # Lazy initialization
        return self.private_abspath
    
    def __getattr__(self, attr):
        if attr == "abspath":
            print "warning: abspath supported only for API consistency with peformance loss. Use get_abspath()" # in real class,this warning should only be printed once.
            return self.get_abspath()
            

n = Node()
print n.get_abspath()
print n.abspath

result:

/a/path
warning: abspath supported only for API consistency with peformance loss. Use get_abspath()
/a/path

Note: I always considered .path and .abspath as public API as they are documented and used in many examples in the documentation. Was that a wrong assumption?




> Le 2 mars 2015 à 09:30, Dirk Bächle <tshortik at gmx.de> a écrit :
> 
> Alexandre,
> 
> On 02.03.2015 09:06, alexandre.feblot at gmail.com wrote:
>> Hi Dirk,
>> 
>> About those new interfaces for accessing node attributes that may get initialized lazily, do I understand here the consequences properly?
>> 
>> - Using directly a_node.path or a_node.abspath *must* be replaced in all SConstructs/SConscripts by the new interfaces if we wan’t them to keep working properly
>> - This lets us with 2 solutions:
>>    1- Do these changes in all our product maintenance branches, and even each time we need to checkout again an old tag we want to compile again.
>>    2- Keep an old Scons 2.3 to build our old code, and change our build infrastructure to be able to have different SCons paths, so we can chose the proper one.
>> 
> 
> sorry, I forgot:
> 
>      3- Factor out all your direct accesses to Node internals into a custom module/Builder, and then wrap it with a check for the SCons version. For 2.3.x and smaller, you access Node attributes as before, and for the newer versions you then branch to using the getter methods.
> 
> This is pretty much what the compat layer would do, which I mentioned in my last reply.
> 
> Best regards,
> 
> Dirk
> 
> 
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150302/9ae53f7f/attachment.html>