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

Python conventions improvements ideas #331

Open
se7entyse7en opened this issue Mar 14, 2019 · 5 comments
Open

Python conventions improvements ideas #331

se7entyse7en opened this issue Mar 14, 2019 · 5 comments

Comments

@se7entyse7en
Copy link
Contributor

se7entyse7en commented Mar 14, 2019

The current status of python conventions is a bit poor. Here are some of the things that I think could be decided and that would help to improve consistency across python projects:

  • supported versions: from some slack discussions it seems to be >=3.5, they could be tested only on travis or using for example tox
  • deps management, packaging and publishing: pip + requirements.txt, pipenv, poetry (I personally like poetry as it also handles packaging and publishing)
  • packaging and publishing: setup.py + twine, poetry
  • virtualenvs compatibility: should the project be compatible only with virtualenvs or maybe even conda?
  • best practices: a common configuration for flake, usage of other tools such as isort for imports sorting
@smacker
Copy link
Contributor

smacker commented Mar 14, 2019

/cc @vmarkovtsev

@vmarkovtsev
Copy link
Collaborator

vmarkovtsev commented Mar 14, 2019

This is the current state of all our ML projects:

  • We support 3.5+. Generally, we support any Python version equal to or newer than in Ubuntu LTS -2 years ago. That is 16.04 and 3.5. Hence we will drop 3.5 in 2020.
  • We use pip and requirements.txt and are totally happy with them, apart from a few minor complaints. The rationale is that the ML folks have never heard about poerty, myself included, and it is completely not widespread in the Python (ML/DS) community. Anaconda is, but no.
  • setup.py + twine. It works - that's all we need from packaging atm.
  • We do not use virtual environments. We always run shared stuff in Docker.
  • This is something we are investigating. There is some common configuration in the latest projects, and the older ones do not use flake at all in favor of vanilla pycodestyle.
  • Type hinting guide is under development. I am not going to force it over the whole company though.

@se7entyse7en
Copy link
Contributor Author

@vmarkovtsev thank you for the explanation!

@smola
Copy link
Contributor

smola commented Mar 19, 2019

We support 3.5+. Generally, we support any Python version equal to or newer than in Ubuntu LTS -2 years ago. That is 16.04 and 3.5. Hence we will drop 3.5 in 2020.

This seems sensible. We should add this already, since it's our current minimum.

deps management, packaging and publishing: pip + requirements.txt, pipenv, poetry (I personally like poetry as it also handles packaging and publishing)

We use pip and requirements.txt and are totally happy with them, apart from a few minor complaints.

Using pipenv for applications would make sense to me. This has been discussed a few times on Slack, but never got a clear picture.

Type hinting guide is under development. I am not going to force it over the whole company though.

It can be a good recommendation for everyone though.

@se7entyse7en
Copy link
Contributor Author

Type hinting guide is under development. I am not going to force it over the whole company though.

I think that really helps to understand the code faster, and it should be a really very nice to have at least for "public" methods. Just as an example we started using type hinting in lookout-sdk and along with sphinx docstring makes the code easy to follow (example).

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

4 participants