[reportlab-users] No usage of recursiveGet/Set/DelAttr

5 views
Skip to first unread message

Claude Paroz

unread,
Feb 28, 2022, 8:17:23 AMFeb 28
to For users of Reportlab open source software
Hi,

I didn't find any usage of
recursiveGetAttr/recursiveSetAttr/recursiveDelAttr in reportlab public code.
So if they are not used in other client code, I guess they could simply
be removed, as the attached patch is doing.

Claude
--
www.2xlibre.net
0001-Remove-recursiveGet-Set-DelAttr.patch

Andy Robinson

unread,
Feb 28, 2022, 8:23:20 AMFeb 28
to reportlab-users
Claude, I see that recursiveSetAttr is used by our commercial product `rml2pdf`.  It's possible we could remove them, as python provides much better tools for that kind of thing than it did in 2001.   We have to scan a few other repositories to see if there are other uses before we can be sure.

- Andy Robinson

www.2xlibre.net_______________________________________________
reportlab-users mailing list
reportl...@lists2.reportlab.com
https://pairlist2.pair.net/mailman/listinfo/reportlab-users



Claude Paroz

unread,
Mar 1, 2022, 2:48:26 AMMar 1
to reportlab-users, Andy Robinson
Hi Andy,

Then maybe it would just be a matter of moving the function(s) to your
internal commercial code?

Claude

Le 28.02.22 à 14:23, Andy Robinson a écrit :

Andy Robinson

unread,
Mar 1, 2022, 10:34:11 AMMar 1
to Claude Paroz, reportlab-users
We have discussed this.  How do we know that there is nobody out there using the function?  Our graphics framework and object hierarchy are quite nested, and so this function was quite useful to us and might have been to others.   There are probably tens of thousands of projects using ReportLab including many in-house ones we have no way to even know about.

Regrettably we did not have any kind of strict separation of external API and internal details when we started, and many times in the last 20 years we have 'tidied something up' and broken somebody else's application.     We feel that unless something is actually broken, or there is a risk, it's safer not to change things for the sake of change.    

There is a more elegant implementation of recursiveSetAttr on StackOverflow, but more elegant can also mean "harder to understand" so we see no need to change it now.

Best Regards

Andy

Claude Paroz

unread,
Mar 1, 2022, 10:50:06 AMMar 1
to Andy Robinson, reportlab-users
OK, fair, I understand your position.

One way to do it progressively would be to show deprecation warnings
when using the functions, before removing them in a future version.
Or simply wait and do it for a future 4.0 version, where the major
version number may signify library users that some compatibility might
be broken (and I detected several other unused functions in the
lib/utils.py file that could be purged in the same time).

But I also understand that the effort might not be worth doing. That's
your maintainer's privilege to make such choices :-)

Claude

Le 01.03.22 à 16:33, Andy Robinson a écrit :

> > <mailto:cla...@2xlibre.net <mailto:cla...@2xlibre.net>>> wrote:
> >
> >     Hi,
> >
> >     I didn't find any usage of
> >     recursiveGetAttr/recursiveSetAttr/recursiveDelAttr in reportlab
> >     public code.
> >     So if they are not used in other client code, I guess they
> could simply
> >     be removed, as the attached patch is doing.
> >
> >     Claude
> >     --

> > www.2xlibre.net <http://www.2xlibre.net>

Andy Robinson

unread,
Mar 1, 2022, 10:54:22 AMMar 1
to Claude Paroz, reportlab-users
On Tue, 1 Mar 2022 at 15:50, Claude Paroz <cla...@2xlibre.net> wrote:
OK, fair, I understand your position.

One way to do it progressively would be to show deprecation warnings
when using the functions, before removing them in a future version.
Or simply wait and do it for a future 4.0 version, where the major
version number may signify library users that some compatibility might
be broken (and I detected several other unused functions in the
lib/utils.py file that could be purged in the same time).

But I also understand that the effort might not be worth doing. That's
your maintainer's privilege to make such choices :-)


Thanks for your understanding.  Old code bases are never very pretty, and the main thing their users want in my experience is "no unexpected changes".    

- Andy
Reply all
Reply to author
Forward
0 new messages