[Libre-soc-dev] liskov substitution principle and type assertions/annotations

lkcl luke.leighton at gmail.com
Wed Aug 10 05:59:06 BST 2022


On Wed, Aug 10, 2022 at 5:20 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Aug 5, 2022, 19:59 lkcl <luke.leighton at gmail.com> wrote:

> 3. type assertions also help IDEs give you the correct information, e.g. if it knows some variable v is a str then it can autocomplete str's methods -- when you type v.isd it can give you v.isdigit. when you hover over a variable, it can tell you it's a str. when you do something like try to append it to a list[int] variable, it can tell you that you messed up there because str isn't int. This is very beneficial as, in my experience, it can speed up writing code by a factor of 2x or more.

i have told you multiple times that you are not to poison the
HDL with type annotations, and that if you absolutely insist
on adding them to put them into a separate file which your choice
of IDE benefits from.

yet you continue not only to fail to do that, you continue to repeat
that "type annotations make things better".

i have told you multiple times that they make code both unreadable
and longer both in width and height by unacceptable percentages
and yet you systematically fail to acknowledge this as being in
any way important.

you have made it absolutely clear that you despise python
but the resentment that you clearly and non-clearly express
is causing me considerable distress and anger at having to
constantly fire-fight and watch out for the repeated systematic
breaking of rules that i have specifically set.

when you can *listen* and respect the rules that i set, rather
than ignore them because of the resentment that you feel
for being "forced" to work on python "because it is not rust-like",
then i will be more inclined to listen to what you have to say.

please *stop* applying rust programming language concepts
and constructs to python.  it is inappropriate and distressing
to me to continue to have to repeat this to you.

l.



More information about the Libre-soc-dev mailing list