[Vote]: Naming conventions in v1.0.0

[AsakusaRinne]

Dear all,

Thank you for your support for TensorFlow.NET and it will publish v1.0.0 which will include many new major features and some break changes 😸. Here's a vote for the possible approaches of naming convention changing in v1.0.0.

Currently, TensorFlow.NET v0.x employs a naming convention inspired by Python, such as void save_model(string model_path). This was done in order to facilitate an easier transition from Python to C# when experienced AI developers were more scarce (around 3-4 years ago). Nevertheless, this naming approach has created some obstacles when using TensorFlow.NET with other C# packages, and also hinders automatic code completion tools like Copilot.

As more experienced AI developers and documentation become available, we believe it's time to reconsider using a C# style naming convention. However, we need to to make upgrading from v0.x easy for our users, even though v1.0.0 could includes major-breaking changes. We want to hear your feedback and opinions on changing the current naming convention.

Please see #1067 for more detailed information on the proposed naming conventions and voting options. You can vote on a particular option by clicking the "like" emoji. Additionally, if you have other ideas, don't hesitate to tell us and we'll really appreciate it.

[AsakusaRinne]

1. Do not change anything of the naming convention, just stay in python-style APIs.

[AsakusaRinne]

2. Provide a C# style binding of tf, tf.keras and so on.

This means that you could use tf.xxx, tf.keras.xxx with C# style APIs. Here's the comparison of the condition before and after the change.

Before:

using static Tensorflow.Binding;

var t = tf.random_uniform(1);

After:

// using static Tensorflow.Binding; // this is also supported
using static Tensorflow.SharpStyleBinding;

var t = tf.RandomUniform(1);

This approach has nearly no impact on upgrading from v0.x to v1.0.0. However, the methods' naming convention is left no change. For example, Tensor.value_index.

[AsakusaRinne]

3. Find a way to automatically change the naming convention to camel case and split them into two packages. (Not sure if the automation could be found but worth a try).

This approach means that Tensorflow.NET will have two set of packages.

TensorFlow.NET
TensorFlow.Keras
TensorFlow.Hub

and

TensorFlow.NET.SharpStyle
TensorFlow.Keras.SharpStyle
TensorFlow.Hub.SharpStyle

It will introduce much inconvenience to the development and make the packages a mess to a certain degree. But it could work for the two groups of users at the same time.

BTW, anyone knows something about automatically changing the method name (not only itself, but also its usages)? Thank you.

[AsakusaRinne]

4. Completely change the naming conventions of all functions and methods. The python-style naming conventions will be totally dropped.

[GadgetNutt]

Unfortuntately, while I sort of agree with SharpStyle, I think it could also be confusing for cross developing. I would say either keep Python style or just drop python style completely and don't use SharpStyle. It makes it easier to compare with Python and migrate code between platforms if necessary. Also since. TensorFlow.NET doesn't implement everything yet, I'm finding I'm having to learn Python right now to implement my neural net. So when I'm comparing the 2 in the future, I would like it to be easy to compare.

[DevNullx64]

The separation into TensorFlow.Net and another package like TensorFlow.py, for example, is a good approach. I admit to being quite confused by the naming conventions and certain workarounds that need to be done to achieve Python-like code. TensorFlow.py would be a minimalistic "wrapper" that simply adds Python-like features for developers who need them on top of a pure .NET C# TensorFlow.Net.

[GadgetNutt]

The separation into TensorFlow.Net and another package like TensorFlow.py, for example, is a good approach. I admit to being quite confused by the naming conventions and certain workarounds that need to be done to achieve Python-like code. TensorFlow.py would be a minimalistic "wrapper" that simply adds Python-like features for developers who need them on top of a pure .NET C# TensorFlow.Net.

That sounds reasonable to me, except one might think it was actually Python then.

[goroggy]

Hi, would it be too cumbersome to offer both versions side-by-side, in the same package? Say, public CamelStyle() => python_style(); public python_style() {....}

[dogvane]

目前的版本和python对比，还是差了很多方法的，目前阶段，命名规则还不建议切换到 c# 样式，这样不方便对照查找与修改。 当然，如果是实验阶段，能出一个自动化工具，自动的将代码里的 python 样式，改为 c# 样式，并用新的独立包发布，也是可以的。但不能作为主版本发布。

[nulldg]

no public interface should ever break C# convention. that's a decision which is essentially forced onto us, and the resulting inconsistency in our code is intractable. if i wanted my code to look like python, i would just use python.

other bindings like OpenTK stick to C# convention and i recommend TensorFlow.NET do the same. i feel very strongly about this so i've been tempted to fork this library to fix the naming myself, but it would be wonderful if the library is either separated into two packages or the python naming convention is dropped entirely.