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

Remove class constants from element factory constructors #9

Draft
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

AvroNelson
Copy link

Moving the Batch Flags, Request Path and Name Attribute values out of the Element Factory initializers and into class constants on the actual element objects. Added some expanded comments and unit tests to verify expected behaviour.

Multiple can_batch_X() methods on the ElementFactory have the values cast to bool as that is what they report to return, but were returning int values.

Copy link

@jeremysnell jeremysnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great changes, just a couple small comments.

s4/clarity/lims.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/lims.py Show resolved Hide resolved
s4/clarity/project.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
@@ -1,6 +1,6 @@
# Copyright 2016 Semaphore Solutions, Inc.
# ---------------------------------------------------------------------------

from s4.clarity._internal.factory import BatchFlags
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move the definition of BatchFlags to ClarityElement to avoid having to import in every ClarityElement.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still have to import it, just from .element instead of from .factory, which sucks, but it is a better place for the definition. I also explictly coded the default of none in.

s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/lims.py Show resolved Hide resolved
Copy link
Contributor

@mgillis mgillis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general this is a mostly good change. Some of the documentation isn't great in terms of actual English, and some of the new functions seem a little unnecessary.

s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
Comment on lines 76 to 78
if hasattr(self.element_class, 'NAME_ATTRIBUTE'):
return self.element_class.NAME_ATTRIBUTE
return "name"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole thing could just be return getattr(self.element_class, 'NAME_ATTRIBUTE', "name"). (I also don't know why it's a function, since why would anyone subclass and override it, but I guess if you really want it to be that's fine)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They were separated out to remove the logic of determining where the name attribute was to be found from the logic of the constructor.
I really like the change you have of passing the default to getattr, that is small enough to put inline into the init.

s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/_internal/factory.py Outdated Show resolved Hide resolved
s4/clarity/lims.py Outdated Show resolved Hide resolved
s4/clarity/lims.py Outdated Show resolved Hide resolved
s4/clarity/lims.py Show resolved Hide resolved
# Using the same RegEx query select out the hostname from the URI
return hostname_match.group(1)

def _get_environment(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that this is a function and nice and clean, it seems like this should be overrideable by passing a param into the constructor, so I can tell the LIMS object it is a test LIMS explicitly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.... I mean the whole thing is pretty suspect in my opinion. I don't think that we can actually declare the machine objective based on the name. Like, if we get a client called GeneTest and they get a server called clarity.genetest.com we will think that every machine, other than their dev machine, is the test machine.
Do we ever consume the output of this variable? It is unrelated to communicating with Clarity.
I would vote to remove it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're probably right. Personally I wouldn't bother trying to remove it as part of this PR since this has been in limbo for a while and should get merged, might as well do it separately so we can argue about it there instead. (or I can after this is merged)

@@ -38,12 +38,13 @@ def __init__(self, lims, element_class):
"""
Creates a new factory to provide interface between Clarity LIMS and the client software.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AvroNelson I meant this line was the one with the typo, sorry :D

@mgillis
Copy link
Contributor

mgillis commented Jan 10, 2020

I made the doc change (and then did some typing changes) in my own PR to Avro's branch. @AvroNelson : AvroNelson#1 for you to review (it will merge onto this branch)

@Mark-Swinkels Mark-Swinkels marked this pull request as draft July 4, 2022 20:22
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

Successfully merging this pull request may close these issues.

4 participants