pymodbus-dev
Add more typing to transaction and base client
there are a couple of CI problems
Hmm, fixed everything except a test coverage percentage check, not sure what to do about that one.
And just for the fun of it, I run into lowering the % in #2239, but instead of lowering the bar, I will examine the cause and add tests.
May I politely suggest, you do typing in this PR and not a lot of code changes !
All code changes made are directly due to issues being flagged by the typing additions.
Adding typing is not always easy, I know @alexrudd2 have had some difficult times with a lot of the code.
BUT, when changing code that have been working for years, then it is important to show why the change is correct, that is most easily done with test cases, which we can run on the old code (dev) and the new code (this PR).
Please stop extending this PR, you still have not solved the basic problems in transaction.py
Adding test files to the mix, will only ensure that you will not get the PR reviewed !
Please stop extending this PR, you still have not solved the basic problems in transaction.py
Yeah, I should probably split off those test fixes, it ended up being more fixes than I expected. Was trying to fix the mypy typing errors in tests calling transaction.py to make it easier to validate typing there. I found a few issues already with the tests not always using the correct types at least.
the only reason to mix test files with production code, is if the production code changes needs changes in test !!!
That is an unbreakable rule, just like the CI rule.
However I can just as well tell you, your test changes are unwanted because the only complicate tests and does nothing to improve the production code.
However I can just as well tell you, your test changes are unwanted because the only complicate tests and does nothing to improve the production code.
I'm confused, the test changes are fixing bugs in the tests flagged by mypy. If the mocking in the tests do not use the correct types then the tests are much less useful aren't they?
We do not run mypy and a number of the other tools an test, specifically because there are a larger number of lines flagged, which actually are ok or even needed.
And can we please agree "bugs" are when something do not want as we want, violating types is surely not in that category (and in many cases because we want it).
We do not run mypy and a number of the other tools an test, specifically because there are a larger number of lines flagged, which actually are ok or even needed.
I'm aware there are currently a lot of mypy errors with the tests...but I see no indication that these aren't fixable by cleaning up the test code in various ways, for example this eliminates method-assign mypy errors in test/test_transaction.py while also eliminating some ugly hacks with how the mocking was being done.
And can we please agree "bugs" are when something do not want as we want, violating types is surely not in that category (and in many cases because we want it).
I mean, tests using the wrong types are kinda a problem IMO as it makes it more difficult to tell if the production code is correct.
And can we please agree "bugs" are when something do not want as we want, violating types is surely not in that category (and in many cases because we want it).
Here I must disagree. :) Although mypy has some false positives, making it happy fixes bugs and prevents new ones. I'd say 20% of the time type errors are actual logic errors, which is high enough to make it worthwhile.
Here I must disagree. :) Although
mypyhas some false positives, making it happy fixes bugs and prevents new ones. I'd say 20% of the time type errors are actual logic errors, which is high enough to make it worthwhile.
Well if there are actual logic errors, then the code do not work as we want, and thus it is a bug.....problem is that mypy is very do not allow to use the full power of python, being a non typed language, e.g. assigning different types to a variable makes mypy mark it, but it's legal and often in test a nice way to test different parameter types,
Well if there are actual logic errors, then the code do not work as we want, and thus it is a bug.....problem is that mypy is very do not allow to use the full power of python
I mean, I think there's usually ways to make tests play nice with mypy while making the test code cleaner like in #2251 and for cases where it's not possible can just add ignores.
being a non typed language
Python is both a strongly typed and a dynamically typed language, it's certainly not a "non typed language" whatever that means.
assigning different types to a variable makes mypy mark it, but it's legal and often in test a nice way to test different parameter types,
IMO not being sufficiently strict with types is a major issue that makes the transaction code hard to work with.
I mean, I think there's usually ways to make tests play nice with mypy while making the test code cleaner like in #2251 and for cases where it's not possible can just add ignores.
I am sure there are.
Python is both a strongly typed and a dynamically typed language, it's certainly not a "non typed language" whatever that means.
It is a non typed language, because you can start using variables without giving them a type, and a variable freely be assigned all kind of types. Python allows typing, but the interpreter do not use that information, which is the definition of a non typed language.
IMO not being sufficiently strict with types is a major issue that makes the transaction code hard to work with.
Yes but it one of the strong features of python, if you want strict typing then start using e,g, C++
It is a non typed language, because you can start using variables without giving them a type, and a variable freely be assigned all kind of types.
So...dynamically typed I think would be what you're referring to here. Where did the term "no typed language" come from? I'm not seeing much of anything in google about that term.
Python allows typing, but the interpreter do not use that information, which is the definition of a non typed language.
This is...not accurate at all, what do you think a TypeError is if the interpreter doesn't use typing information?
Python is a strongly typed language, strong typing means that variables do have a type and that the type matters when performing operations on a variable.
Yes but it one of the strong features of python
I think you're mixing up Python with JavaScript-like languages that are both weakly typed and dynamically typed. Python's type system is more lenient than C++ while still being strongly typed which I prefer to weakly typed languages like JavaScript.
if you want strict typing then start using e,g, C++
C++ is statically typed with fairly strong typing. Python is dynamically typed with similarly strong typing(I think in some ways even stronger than C++), one reason I like Python is due to it being dynamically and strongly typed. I try to stay away from JavaScript-like languages when possible in general primarily due to them using weak typing which generally results in more bugs.
So...dynamically typed I think would be what you're referring to here. Where did the term "no typed language" come from? I'm not seeing much of anything in google about that term.
No dynamically typed (e,g, java) is different, as the name indicates a type is added dynamically, and the interpreter uses that to e.g. assign storage.
This is...not accurate at all, what do you think a TypeError is if the interpreter doesn't use typing information?
For the interpreter everything is stored in a object class, of course within that class there can be types.
I think you're mixing up Python with JavaScript-like languages that are both weakly typed and dynamically typed. Python's type system is more lenient than C++ while still being strongly typed which I prefer to weakly typed languages like JavaScript.
No I am not ! I have been around from before all these fancy languages, and spent quite a lot of time helping make parsers and interpreters.
Fact is, you can write a perfectly valid python program, without using a single type definition, and if you care to take a look at the python parser, it skips all type information, which is actually currently one of the bigger problems for making an optimizer in coython.
Of course the object class used by the runtime, do checks on assignment etc, but that is due to the internals of the object, not the interpreter,
C++ is statically typed with fairly strong typing. Python is dynamically typed with similarly strong typing(I think in some ways even stronger than C++), one reason I like Python is due to it being dynamically and strongly typed. I try to stay away from JavaScript-like languages when possible in general primarily due to them using weak typing which generally results in more bugs.
Your sentence is wrong. python allow typing, but do not use that information as it is purely optional.
Easy proof, make an array with 1.000.000 entries with a mixture of integers and floats, measured the actual memory footprint. Then type the array and use only integers, the active memory footprint is the same. A typed language would use the typing information to optimize the memory footprint.
But anyhow believe what you want to believe, I am too old to give free lessons in compiler techniques.
No dynamically typed (e,g, java) is different, as the name indicates a type is added dynamically, and the interpreter uses that to e.g. assign storage.
Java is actually statically typed, JavaScript is dynamically typed at least based on the definitions that I'm familiar with: "A statically-typed language is a language (such as Java, C, or C++) where variable types are known at compile time. In most of these languages, types must be expressly indicated by the programmer; in other cases (such as OCaml), type inference allows the programmer to not indicate their variable types."
For the interpreter everything is stored in a object class, of course within that class there can be types.
Everything may be an object but "there can be types" isn't very precise as "Every object has an identity, a type and a value.", I think this is somewhat important for making python's strong typing system work.
Fact is, you can write a perfectly valid python program, without using a single type definition, and if you care to take a look at the python parser, it skips all type information, which is actually currently one of the bigger problems for making an optimizer in coython.
That's true, "The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.". It is of course also true that it's harder to optimize dynamically typed languages like Python.
Your sentence is wrong. python allow typing, but do not use that information as it is purely optional.
The sort of typing I think you are referring to is just optional type annotations, so it is true that typing is optional in that sense. However "In a dynamically typed language, a variable is simply a value bound to a name; the value has a type -- like "integer" or "string" or "list" -- but the variable itself doesn't.".
Easy proof, make an array with 1.000.000 entries with a mixture of integers and floats, measured the actual memory footprint. Then type the array and use only integers, the active memory footprint is the same. A typed language would use the typing information to optimize the memory footprint.
That's true, "The Python runtime does not enforce function and variable type annotations.". "In a dynamically typed language, objects still have a type, but it is determined at runtime."
But anyhow believe what you want to believe, I am too old to give free lessons in compiler techniques.
I think for the most part you are just using different terminology than what I'm familiar with.
Most people do not care about how the compiler works as long as it does the job, which is a pity because it often leads to programs with a bad performance.
If you solely look at typing from the outside, you really miss a lot, in order to make big scale programs.
As you correctly noted dynamically typed means a variable is assigned a type at runtime...but you missed the point everything in python is inherited from THE Object so the type of everything in python is Object, This is the reason why you can e,g, assign a string to a function, and thus totally change how it works.
But as I said, stay in your beliefs!
Fact for this project, typing is accepted because a couple of contributors care about it. Every change that complicates the code, without adding other benefit than pleasing mypy is not accepted.
Most people do not care about how the compiler works as long as it does the job, which is a pity because it often leads to programs with a bad performance.
I am heavily involved with python toolchain/package integration as part of the open source buildroot embedded Linux cross-compilation project and have worked on complex cross language toolchain integrations such as buildroot's python rust extension integration(used by libraries like python-cryptography which use pyo3 bindings). So I'm not at all unfamiliar with a lot of lower level details regarding the Python toolchain/interpreter. Python is not a particular easy language to cross compile either but buildroot has excellent support for python cross compilation partially due to a lot of work I've done on it(pep517 build system integrations for example).
you missed the point everything in python is inherited from THE Object so the type of everything in python is Object, This is the reason why you can e,g, assign a string to a function, and thus totally change how it works.
I don't think I'm disagreeing with that, that's just an implementation detail of python's dynamic typing system.
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This PR was closed because it has been stalled for 10 days with no activity.