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

GenericDiffractomer and AbstractCollect #18

Closed
IvarsKarpics opened this issue Mar 4, 2016 · 10 comments
Closed

GenericDiffractomer and AbstractCollect #18

IvarsKarpics opened this issue Mar 4, 2016 · 10 comments

Comments

@IvarsKarpics
Copy link
Member

Hi all,

  • GenericDiffractometer. So for sure this is not a final version, but an idea what could be a minimal set of function to define API. As a base I used MD2 and MD3. I assume that some things could go out, for example: some states or hardware objects (remove them all and make fully abstract?). As an example you can look at Qt4_DiffractometerMockup.py and EMBL/EMBLMinidiff.py as an implementation. I would encourage people to look at this and slowly start to use it. As an example I can mention GenericSampleChanger that is used as a base for all sample changer and works well. I think diffractometers also should have a generic class and maybe separate directory.
  • AbstractCollect is a minimized version of AbstractMulticollect.
@JieNanMAXIV
Copy link
Contributor

A quick question regarding the naming conventions. Currently it's a mix of camelCase and underscore. To solve the legacy issue and make the APIs compatible for different sites and mockups, both are used, such as self.startAutoCentring = self.start_automatic_centring, which is a nice quick solution. However it's not implemented in all mockups and hwobj and quite some "bugs" were due to this.

So it would be nice that at least in the future if we could agree on ONE. Because currently both naming conventions are still showing up in the new codes. What do you say?

@IvarsKarpics
Copy link
Member Author

I would wote for the snake style (the one with underscores, for example self.start_automatic_centring). In fact there was before discussion about this. I think we should once define it. Based on PEP https://www.python.org/dev/peps/pep-0008/

  • Function Names: Function names should be lowercase, with words separated by underscores as necessary to improve readability.
  • Class Names: Class names should normally use the CapWords convention.
  • Method Names and Instance Variables: Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability. Use one leading underscore only for non-public methods and instance variables.

@JieNanMAXIV
Copy link
Contributor

Thanks! We will try to follow the same rules.

From: Ivars Karpics [mailto:[email protected]]
Sent: Thursday, March 17, 2016 11:48 AM
To: mxcube/HardwareObjects
Cc: Jie Nan
Subject: Re: [HardwareObjects] GenericDiffractomer and AbstractCollect (#18)

I would wote for the snake style (the one with underscores, for example self.start_automatic_centring). In fact there was before discussion about this. I think we should once define it. Based on PEP https://www.python.org/dev/peps/pep-0008/

  • Function Names: Function names should be lowercase, with words separated by underscores as necessary to improve readability.
  • Class Names: Class names should normally use the CapWords convention.
  • Method Names and Instance Variables: Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability. Use one leading underscore only for non-public methods and instance variables.


You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-197815973

@meguiraun
Copy link
Contributor

In the v3 development we are using camelCase, although we are not very consistent. In fact we did a pr called Pep8 with camelCase... and we have code with snake_style... bluurrrr

Anyway, if we all agree to follow pep8 it's fine for me, the rules are already defined so it is just a matter of decision... and refactoring, but doable.

@mguijarr
Copy link
Member

👍 for PEP8 and snake style for Python code.

@JieNanMAXIV
Copy link
Contributor

I have a question on how to copy greenlet in python.
To solve the legacy issued mentioned above and make the code more compatible, both snake and camelCase are defined as shown below. This works well for methods and dictionaries, but not for greenlet (return of gevent.spawn) as in the case of self.currentCentringProcedure. Any suggestion of a workaround is appreciated!

self.currentCentringProcedure = self.current_centring_procedure
self.start3ClickCentring = self.start_manual_centring
self.startAutoCentring = self.start_automatic_centring
self.imageClicked = self.image_clicked

@mguijarr
Copy link
Member

You can move all those aliases including the greenlet in __getattr__:

def __getattr__(self, attr):
    if attr.startswith("__"):
        raise AttributeError(attr)
   else:
        if attr == "currentCentringProcedure":
            return self.current_centring_procedure
       ...

It's a bit ugly, but this is ugly with aliases too so... ;)

@JieNanMAXIV
Copy link
Contributor

Great, thanks!

From: Matias Guijarro [mailto:[email protected]]
Sent: Tuesday, March 22, 2016 9:17 AM
To: mxcube/HardwareObjects
Cc: Jie Nan
Subject: Re: [HardwareObjects] GenericDiffractomer and AbstractCollect (#18)

You can move all those aliases including the greenlet in getattr:

def getattr(self, attr):

if attr.startswith("__"):

    raise AttributeError(attr)

else:

    if attr == "currentCentringProcedure":

        return self.current_centring_procedure

   ...

It's a bit ugly, but this is ugly with aliases too so... ;)


You are receiving this because you commented.
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-199693907

@IvarsKarpics
Copy link
Member Author

Phases become methods (free to develop new phase, based on a current diffractometer), head types and centring methods as dict.
Clean up MiniDiff.

@IvarsKarpics
Copy link
Member Author

Also topic for 2.3 #82

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

No branches or pull requests

4 participants