Make class transformation one-way only

[interactive-sonification]

Make class transformation one-way only

[wiccy46]

@aleneum @thomas-hermann , Please comment.

[thomas-hermann]

the (resp. my) main use case for to_sig() is resynthesis of a sound signal after manipulation in the spectrum or STFT representation. How would you propose to achieve that otherwise: e.g. Asig("myfile.wav").to_spec().weight([0,0,1,1], freqs=[0, 400, 600, 22050]).to_sig()
or
Asig("myfile.wav").to_spec().ranomize_phases().to_sig()
for illustration with a yet none-existent but probably useful method randomize_phases().

In my courses the manipulation is done in code manipulating / overwriting the Aspec's rfftsig member variable directly, e.g. aspec.rfftsig[:200] = 0 for a high-pass filter. In such cases, I agree that Asig(aspec).plot().play() is useful and maybe even better than aspec.to_asig().plot().play()

Your proposed solution by accepting Aspec and Astft as arguments in the Asig constructor would solve the circular imports, but to my opinion impair code readability, e.g. Asig(Asig("myfile.wav").to_spec().ranomize_phases()) is less easy to follow than the above example. But I favour adding these to the Asig constructor, yet can we in these cases imply sr from the aspec/astft instance?

Wouldn't it be ok to always import Asig and then so forego circular Asig imports for to_asig()?

[wiccy46]

@thomas-hermann

Wouldn't it be ok to always import Asig and then so forego circular Asig imports for to_asig()?

Not sure what you meant by always import Asig. Can you give some example ? It is inheritly an circular import issue where we need Aspec in Asig and Asig in Aspec, and using from .foo import bar style.

[thomas-hermann]

sorry I meant to import the module itself rather than importing object/function from the module. Haven't dealt before with this issue of circular imports but wouldn't import pya in Aspec.py and Astft.py solve the issue of partially initialized modules?

An alternative path (probably even better, as Asig, Aspec and Astft are so related) could be to merge the content of the files aspec.py, astft.py and asig.py into a single file, e.g. core.py: If I am not mistaken grouping several classes in a single file is even recommended and pythonic... - any thoughts on this?

[wiccy46]

Yea, I think the way to avoid circular import while allowing 2-way transformation is remove all relative import where this transformation may happen: see:

pya/pya/asig.py

Line 15 in 2e2cd7b

import pya.amfcc

I am open to having a core.py at some point. But this is a larger discussion with some major redesign. We can collect thoughts on a new issue.

[wiccy46]

Close this now. Since we will no longer take this 1-way approach.

[aleneum]

Happy new year everyone!

could be to merge the content of the files aspec.py, astft.py and asig.py into a single file, e.g. core.py

while the 'one class per file' is not as heavily enforced in python as for instance in Java or C#, I'd recommend to keep things separated as much as possible. The complexity of core.py could also impact test_core.py. You could of course split up tests (test_core_asig, ...) but my point is that the maintainability might be negatively impacted. Decoupling Asig/Aspec/etc however is a good idea. A core.py could be used for decoration and/or composition since the conversion itself is not a core functionality of the respected class but rather a convenience feature.

import pya.amfcc

Coupling in general should be avoided. The goal should not be to silence the compiler/linter/interpreter but rather understand why this might be an issue and make a conscious choice about which design to follow.
The coupling for two-way-conversion is 'by design' though and could be resolved by for instance some 'factory/mixin' decoration/inheritance (the strong typing approach). I'd suggest however to keep imports for conversion situational.

# classA.py

    def to_ClassB(self):
        # this could be from .classB import ClassB
        # but it does not add much to readability in this case
        import pgk.classB
        return pgk.classB.ClassB.fromClassA(self)

# classB.py

    @staticmethod
    def from_ClassA(x):  # could be x: 'pgk.classA.ClassA' for mypy
        import pgk.classA
        x: pgk.classA.ClassA  # for typing
        return ClassB(param_a=x.param_a, param_b=x.param_b)

Situational imports declutter the general imports (and in this case the constructor) while keeping the convenience to_X methods attached to each class. I am all for typing and keeping things as well defined as possible but we should not abandoned all the cool dynamic and flexible functionality that scripting languages offer.