Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HP/Agilent/........Keysight #35

Open
scasagrande opened this issue Aug 7, 2014 · 3 comments
Open

HP/Agilent/........Keysight #35

scasagrande opened this issue Aug 7, 2014 · 3 comments

Comments

@scasagrande
Copy link
Contributor

So the split is now official, the T&M section of Agilent has been spun off once again and is now called Keysight. For each of the two renames, the instruments sold at the time were renamed, but kept the same model number. That is, some HP gear was then sold under the Agilent name, and some Agilent gear is now for sale under the Keysight name, and some HP gear sold under all three (for example the 6624a). This presents some namespace issues.

The way I see it we have a few options:

  • Put everything under one name (say, HP), and have duplicates under the Agilent and Keyspace names. This would require each individual class to also be imported into each one with a different name (ik.HP.HP1234, ik.Agilent.Agilent1234, ik.Keysight.Keysight1234).
  • Put everything under one name and only that one. Cleanest option, but people might not know about the naming history of the company. Some people will always call the gear HP, while some might not know that Keysight originally came from HP.
  • Provide namespace overlap for only the instruments that actually were sold under multiple names. This would require doing a little bit of research for each instrument.
  • Ignore it under the assumption people will look at the docs for all three to find their instrument. Not the greatest option as again not everyone knows about the naming history of the company, and really, who reads the docs?
@cgranade
Copy link
Contributor

cgranade commented Aug 7, 2014

I don't know what to suggest for this, frankly, as there's no truly good option. One idea would be to, in instruments/agilent/__init__.py have something like from instruments.keysight import Keysight1234 as Agilent1234 to provide aliases, but that's a maintainability nightmare.

In any solution, though, we should focus on not breaking (or at least minimally breaking) existing code.

@scasagrande
Copy link
Contributor Author

Thankfully as of right now, all the Agilent classes still need to be refactored so they need to be broken either way.

@cgranade
Copy link
Contributor

cgranade commented Aug 7, 2014

Well, there's that, I suppose. It occurs to me we have deprecation decorators too, so that we can raise a warning when importing Keysight classes from Agilent namespaces.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants