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

Vasily vasslitvinov at pisem.net
Mon Mar 2 15:32:00 EST 2015


Hi everyone,

Why cannot .path, .abspath, etc. become properties (with getters set to
.get_path, .get_abspath, etc)? What's the need to break existing API? I
think there're TONS of files which are using those functions... and
thinking about patching all those makes me really sad :(

Thanks,
Vasily

2015-03-02 12:14 GMT+03:00 <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
>
>
>
> _______________________________________________
> 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/81a4b2c6/attachment.html>


More information about the Scons-dev mailing list