On Fri, Jun 14, 2024 at 12:00 PM Patrick Robb <pr...@iol.unh.edu> wrote:
>
> On Fri, Jun 14, 2024 at 11:03 AM Dean Marx <dm...@iol.unh.edu> wrote:
> > + def vlan_filter_set_on(self, port: int = 0, verify: bool = True):
> > + """Set vlan filter on.
> > +
> > + Args:
> > + port: The port number to use, should be within 0-32.
> > + verify: If :data:`True`, the output of the command is scanned
> > to verify that
> > + vlan filtering was enabled successfully. If not, it is
> > + considered an error.
> > +
> > + Raises:
> > + InteractiveCommandExecutionError: If `verify` is :data:`True`
> > and the filter
> > + fails to update.
> > + """
> > + filter_cmd_output = self.send_command(f"vlan set filter on {port}")
>
> I wonder whether, when convenient, we want to name the methods more or
> less 1:1 according to the actual testpmd text command they send? I.e.
> in this case should the method be named vlan_set_filter_on instead of
> vlan_filter_set_on (aligns better with "vlan set filter on {port}")?
> The intellisense provided by the testpmd methods is indeed a QoL
> improvement for folks writing testsuites, but at the same time people
> who use testpmd will always have the real commands ingrained in their
> thoughts, so if we try to stay as true to those as possible, we get
> the stability and intellisense and also the method names are still
> intuitive.
I generally try to name these methods in a more human-readable way, so
my intuition would lean more towards naming it something like
`set_vlan_filter_on` or `set_vlan_strip_on`. I could see how it might
make it easier for some testpmd developers, so I'm not sure which
would be better. Personally, as someone who is less familiar with all
the ins and outs of testpmd, I prefer the human-readable approach.
>
> Maybe even think tiny things like renaming the method set_forward_mode
> to set_fwd_mode to align 1:1 with testpmd is good.
>
> That's just my perspective though - I would be interested to see
> whether others feel the same or not.
>
<snip>
> > 2.44.0
> >
