[WIP] Organizational review

[Funth0mas]

Organizational review summary:

• Add canmatrix.formats package
• Unify/define formats interface, consider to use zope.interface or simply abc.abstractclass
• canmatrix.canmatrix module should be renamed - canmatrix.core ??
• Possibly expose a particular few things via canmatrix.some_thing() - what classes ??
• Decide and apply a consistent import 'format'
  • No from module import * (!)
• Isolate CLI from library rather than colocating (use cli or cmd module?)
• Use CLICK instead of optparse
• pathlib2 or os.path ?
  • Well, decide one way or the other, altendky preference is for pathlib stuff.
• snake_case for all except of classes, classes with UpperCamel - in progress
• loadb for loading any format from a byte sequence
• static typing
• mypy running in CI
• check and resolve class-wise duplicities (del_frame() vs remove_frame(), comment vs comments)
• remove useless cm prefix from some files
• ??

[altendky]

I'm not big on the cm prefixes as we already have the canmatrix package (the outermost one). It would be nice to never canmatrix.canmatrix as the second one really describes nothing useful.

As to interfaces, my impression from discussions in #python is that zope.interface is the thing to learn from and use, not stdlib (such as abc).

Anyways, you are talking about moving canmatrix.dbc to canmatrix.converters.dbc? If so they are presently referred to as formats I think?

[altendky]

If we're talking about an overall organizational review (I'd rather make an overall plan first then shift everything around, I'm sure some opinions will change as we discuss various points) then I'll add that we might need a misc/utils or whatever module for things like grouper() (unless we use one of the libraries that provides tools like this).

https://github.com/ebroecker/canmatrix/pull/224/files#diff-c1624d42e3750ac47cb2bbd3c178a5d0R536

[Funth0mas]

Bad name, of course I thought formats.
Let cancel this ticket and make it somehow better...later... But I'm afraid I won't help a lot with it :-(

[Funth0mas]

Concerning the prefix, only now I get the cm stands for 'canmatrix', not 'converter'. Yes, I'm not analphabet, I see the converter is not comverter :-) . Does not matter.

[altendky]

We can rename the ticket or make a new one, no matter to me. I see a few things at the moment, let's build the list if there are more. If we are expecting to get more tests in place soone than later, maybe we continue that first before any reorganization.

• Add canmatrix.formats package
• canmatrix.canmatrix module should be renamed
• Possibly expose a particular few things via canmatrix.some_thing()
• Decide and apply a consistent import 'format'
  • No * imports
• Isolate CLI from library rather than colocating
• pathlib2 over os.path
  • Well, decide one way or the other, my preference is for pathlib stuff.
• lowerCamel or snake_case?

[ebroecker]

my 2 cents about overall organizational review

• I want to create a release (0.7) more or less the current development state (gonna check if some bugs should be fixed)
• after that I am open to abandon python2 support
• after that I am very open for cleaning up the code and reorganizing it
• certainly it would also be an option to work for these things in a branch.

@altendky , @Funth0mas : What would you prefer?

[altendky]

• This isn't urgent for me so waiting until after a release seems fine.
• I expected to give more notice than that for dropping py2. I don't know how we go about making sure people notice but I would say we at least have a release which notifies of imminent loss of py2 support before releasing a version that doesn't support py2 (or makes no promises of support for it). I only brought it up because I don't want to be continuing to support it in 2025 simply because we didn't get around to warning anyone it was going away.
• Definitely do it in a branch. Definitely don't let the branch linger. Yeah, git can handle moves but it's just another layer and let's not go begging for merge trouble.

How about we add another thing before a reorg. I don't recall offhand how inconsistent we are but let's pick an import style policy and implement it first. I personally nearly always use the form import canmatrix.formats then canmatrix.formats.load(). As opposed to from canmatrix.formats import load or import canmatrix.formats as f or from . import formats or... If we are reorganizing we'll be changing imports. If we are changing imports we might end up changing lots of names used in code. Mixing it all together seems not great. (I added this to the list of overhauls to consider)

[altendky]

added the following to the list

• Isolate CLI from library rather than colocating

[Funth0mas]

• don't use import *

[ebroecker]

• loadb for loading any format from a byte sequence (canmatrix.formats.loads() fails due to undefined StringIO #103)