[chirp_devel] [PATCH] [ft4]rework code for progkeys [#6583]

[Dan Clemmensen]

My apologies. I did not actually intend to commit the directory.register.
It was there for testing and I just did not see it. I don't really know to
resubmit a patch starting from where I am now, but I will puzzle it out
somehow.   Is the .img file acceptable?

About "class scope": it really is an official part of Python: I did not
make it up. It's exactly what we wanted to use here: a variable that is
only accessible within a class, but not in its superclasses, but is a
single variable shared amongst all members of the class.  I am new to
Python, so I do not know which language constructs are conventionally
simply not used by developers. I will change this to conform to norms. Note
that many of the scalars (e.g., MAX_MEM_SLOT) are a class scope, not
instance scope.

I found out about class scope during testing, when working with
group_descriptions. I thought I could simply modify the global from inside
the FT-65 class. Nope, that affected the FT4. Then I figured I could just
append  in FT-65 __init__. Nope, that causes the append to occur multiple
times if the main code instantiates multiple FT-65s. That's when I finally
figured out the differences between global, instance, and class variables
in Python.   If the driver were only ever used in code that only works with
a single radio during any particular run, I would never have seen this.

On Wed, Mar 13, 2019 at 8:30 AM Dan Smith via chirp_devel <
chirp_devel at intrepid.danplanet.com> wrote:

> > # don't register the FT-65 in the production version until it is tested
> > -# @directory.register
> > + at directory.register
>
> Looks like you need to remove the comment as well. Assume you will add
> this to the wiki when it's merged, right? Also, would you mind putting
> something in the commit message to indicate that a new radio is
> (effectively) added here? Right now it looks to just be a refactor or bug
> fix, but it registers a whole new radio, which is a little obscure.
>
> > class YaesuFT65Radio(YaesuSC35GenericRadio):
> >     MODEL = "FT-65R"
> >     _basetype = BASETYPE_FT65
> > @@ -1112,6 +1125,8 @@
> >     class_group_descs =
> copy.deepcopy(YaesuSC35GenericRadio.group_descriptions)
> >     add_paramdesc(
> >         class_group_descs, "misc", ("compander", "Compander", ["OFF",
> "ON"]))
> > +    CLASS_SPECIALS = list(SPECIALS)    # a shallow copy works here
> > +    CLASS_SPECIALS[-1] = FT65_PROGS    # replace the last entry (P key
> names)
>
> I'm surprised this even works, but even if it does, it's kinda icky. When
> you respin for the comment, can you just define FT65_SPECIALS at module
> scope, get it set properly, and then just assign it here?
>
> Thanks!
>
> --Dan
>
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20190313/0b15aeb9/attachment-0001.html