Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Structuring Your Project

docs.python-guide.org

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Structuring Your Project

#31

Post by theHamsta »

Datenstrom wrote: post #8
zomglings wrote: post #4

When I'm just learning a new programming language or framework, I prefer to have something like create-react-app [0], django-admin startproject [1], cargo new [2], or lein new [3]. Guides like these are just full of (the wrong type of) rabbit holes. Just give new people something that lets them work productively as soon as possible and refer them to language documentation to understand how features of the language or…

`poetry new`[0] is what you are looking for, previously I have used pyscaffold[1] but I like the pyproject.toml from PEP 518[2] better than all the old stuff. Unfortunately poetry does not set up docs like pyscaffold does though. [0]: https://poetry.eustace.io/ [1]: https://pyscaffold.org/en/latest/ [2]: https://www.python.org/dev/peps/pep-0518/

Psyscaffold has a --pyproject option (or at least an add-on linked in the readme, don't remember)

Re: Structuring Your Project

#32

Post by Hamuko »

raziel2p wrote: post #23

Most of the advice here seems okay but this stuck out to me: foo += 'ooo' # This is bad, instead you should do: foo = ''.join([foo, 'ooo']) This seems like such a silly micro-optimization. I also have to question its validity, even in scenarios where you're working with huge strings.

As far as I am aware, str.join instead of str += is just a legacy optimisation that is not really valid when developing for modern Python versions.

Re: Structuring Your Project

#33

Post by ptx »

Datenstrom wrote: post #8
zomglings wrote: post #4

When I'm just learning a new programming language or framework, I prefer to have something like create-react-app [0], django-admin startproject [1], cargo new [2], or lein new [3]. Guides like these are just full of (the wrong type of) rabbit holes. Just give new people something that lets them work productively as soon as possible and refer them to language documentation to understand how features of the language or…

`poetry new`[0] is what you are looking for, previously I have used pyscaffold[1] but I like the pyproject.toml from PEP 518[2] better than all the old stuff. Unfortunately poetry does not set up docs like pyscaffold does though. [0]: https://poetry.eustace.io/ [1]: https://pyscaffold.org/en/latest/ [2]: https://www.python.org/dev/peps/pep-0518/

I never tried Poetry because of this somewhat worrying part of installation instructions: "The installer installs the poetry tool to Poetry's bin directory ... located at $HOME/.poetry/bin ...This directory will be in your $PATH environment variable".

The directory will be in my PATH? That makes me wonder what else it might take the liberty to reconfigure on my system.

But, reading the installer script, it seems like it at least prompts you for confirmation first, so perhaps I'll try it.

Re: Structuring Your Project

#35

Post by calpaterson »

buschkowitz wrote: post #34

I find myself coming back to this guide whenever I set up a new project: https://sourcery.ai/blog/python-best-practices/

A general ignore_missing_imports=True in mypy.ini is very bad advice. This will hide lots of real errors. It's surprisingly easy to set up mypy such that it will silently not check types in many files.

Additionally I can't be the only person who utterly despises pipenv. It is confusing for most people who don't know python packaging internals, phenonomially slow for everyone else and besides discourages building proper distributables (or:wheels).

Re: Structuring Your Project

#36

Post by teddyh »

raziel2p wrote: post #23

Most of the advice here seems okay but this stuck out to me: foo += 'ooo' # This is bad, instead you should do: foo = ''.join([foo, 'ooo']) This seems like such a silly micro-optimization. I also have to question its validity, even in scenarios where you're working with huge strings.

If you use += in a loop over a sequence, then you should replace it with a single line of join(), which should be more efficient. Otherwise you’re absolutely right.

Re: Structuring Your Project

#37

Post by greymalik »

calpaterson wrote: post #35
buschkowitz wrote: post #34

I find myself coming back to this guide whenever I set up a new project: https://sourcery.ai/blog/python-best-practices/

A general ignore_missing_imports=True in mypy.ini is very bad advice. This will hide lots of real errors. It's surprisingly easy to set up mypy such that it will silently not check types in many files. Additionally I can't be the only person who utterly despises pipenv. It is confusing for most people who don't know python packaging internals, phenonomially slow for everyone else and besides discourages building prop…

What do you do instead of pipenv?

Re: Structuring Your Project

#38

Post by bvrmn » 

  To give the individual tests import context, create a  tests/context.py file:
  import os
  import sys
  sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))
Or you can convert your tests directory to package by placing __init__.py. It's pretty amazing that Kenneth Reitz uses this ugly solution.

Re: Structuring Your Project

#39

Post by calpaterson »

greymalik wrote: post #37
calpaterson wrote: post #35

Earlier quoted context omitted.

A general ignore_missing_imports=True in mypy.ini is very bad advice. This will hide lots of real errors. It's surprisingly easy to set up mypy such that it will silently not check types in many files. Additionally I can't be the only person who utterly despises pipenv. It is confusing for most people who don't know python packaging internals, phenonomially slow for everyone else and besides discourages building prop…

What do you do instead of pipenv?

Pipenvs attempts to replace all other tooling to the answer is: all other tooling. Specifically, setuptools via either setup.py or setup.cfg. pbr, virtualenvs, tox, pip-tools, pip, etc are all useful. Anything that does not take 5-10 minutes to recompute dependencies basically!

Re: Structuring Your Project

#40

Post by buschkowitz »

calpaterson wrote: post #39
greymalik wrote: post #37

Earlier quoted context omitted.

What do you do instead of pipenv?

Pipenvs attempts to replace all other tooling to the answer is: all other tooling. Specifically, setuptools via either setup.py or setup.cfg. pbr, virtualenvs, tox, pip-tools, pip, etc are all useful. Anything that does not take 5-10 minutes to recompute dependencies basically!

That is a big weakness, I agree. But the mental tax of having to remember how to use >5 cli tools vs one is definitely pro pipenv for me.
Post reply on HN