Adding type hints

[codingchipmunk]

Hello everyone,
I would like to go through the code in the current master-branch and add type hints to most stuff.
However I wanted to ask if this enhancement would be desired or categorically rejected before I put in the work.

I am currently developing a system which will rely heavly on neo and I believe adding type hints will be beneficial for developing systems based on neo. Also data scientists will most likely also profit from this, as Visual Studio Code and other IDEs begin to support Jupyter notebooks and hence can also make use of the hints.

[apdavison]

That would be very welcome.

[JuliaSprenger]

Hi @codingchipmunk I agree that would be a very nice idea. Depending on the extend to which you want to implement typing this might become a huge change, but even if you start with some classes this will definitely improve the code. Thanks already in advance!

[samuelgarcia]

Hi all,
I will be the grumpy guy.
Sorry for that.
I do not like to much the type hint in python.

Maybe I am too old and do not adapt fast enought, my feeling is that this python type hint is usefull mainly for vscode checking.
I don't see a clear advantage between the verbosity added in the code and the global benefit.

Further more when playing with args that can be numpy.array or list or None. It become more comlex.
Herewe also will have quantity object (scalar or vector).
neo is not only str/int/float
To cover all possible input, the machinery behind type hints could be become complex in neo.
Maybe I am wrong.

I would vote for a call for discussion.

Sam, the grumpy

[apdavison]

I understand where you're coming from, Sam. For smaller projects, or for applications rather than libraries, I tend to agree that the cost sometimes exceeds the benefits.

For a project like Neo, however, which is a dependency for many other projects, I think

1. the process of adding type hints tends to improve the code, as it catches bugs and exposes hidden assumptions and corner-cutting;
2. having an explicit interface makes it easier for projects that depend on Neo to use it correctly;
3. you get IDE support, as mentioned.

(by the way I am planning to add type hints to PyNN sometime in the next 12 months, and for that I'll need to at least have type stubs for Neo.)

As a compromise approach, how about putting the type information into .pyi stub files? This avoids adding verbosity to the main code base, but makes the type/interface information available to people who need it. (The disadvantage is that it's more effort to keep the .py and .pyi files in sync).

[JuliaSprenger]

Let's wait for a quantities release including typing and then include it in the core library.

[joschaschmiedt]

I added type hints to ExampleRawIO to make writing a new I/O module easier: #1229

[JuliaSprenger]

Let's wait for a quantities release including typing and then include it in the core library.

This is implemented in python-quantities/python-quantities#206

Update: We decided to include typing directly in the code, not using .pyi files.

[codingchipmunk]

(Sorry, I accidentally pressed the wrong button and closed the issue.)

Let's wait for a quantities release including typing and then include it in the core library.

This is implemented in python-quantities/python-quantities#206

Update: We decided to include typing directly in the code, not using .pyi files.

Is this also true for quantities? @n-takumasa has opened python-quantities/python-quantities#218 where he added additional changes to mine, so it should pass mypy now.

[apdavison]

I've merged python-quantities/python-quantities#206 and python-quantities/python-quantities#218, and I'll make a new quantities release including the type hints in the next week or so.

[apdavison]

ok, so it took longer than I intended to get round to the quantities release, but v0.15.0 now contains type hints. Many thanks @codingchipmunk and @n-takumasa for your work on that