Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.  This is especially recommended for binary packages to ensure reproducibility, and is more commonly ignored for libraries.

This is taken from https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control

with "main".

First and foremost I think that requiring such a complicated gitignore for JetBrains IDEs is a failure on JetBrains part in structuring their project setting.  I also feel that it should be included in the `Python.gitignore` due to its popularity and due to the frequency of requests.  A quick search for `PyCharm` PRs shows 81 closed PRs requesting it be added and if searching for `.idea` you can see many more have been requested.  However I understand the maintenance burden in including it when a user can manually merge the two files themselves so I understand why the maintainers have opted to maintain it seperately.  

The main problem I see is that with many people adding the `Python.gitignore` at project creation through the Github UI and the `JetBrains.gitignore` being in the Global folder and makes it less discoverable than it should be.  

This PR adds a comment for people adding the `Python.gitignore` directing them to the global `JetBrains.gitignore` which should solve this issue in a way that is acceptable for the maintainers, since comment-only sections already exist for `pyenv` and `pipenv`.

pip generated this folder for a few versions, as part of it's initial
implementation of PEP 517.

pip has not generated this folder for a few versions now, so it should
be OK to remove this from the standard gitignore file.

This reverts commit e931ef7f.

PyB 0.12 uses `$project_root/.pybuilder/` for internal venvs.

Cython extension modules built with `gdb_debug=True` spit out debug symbols in the `cython_debug` directory at the top level of the project. The files in this directory contain hardcoded paths and are not shareable/meaningful across environments, so I think it makes sense to include them in a default Python .gitignore.

pytype is a static type analyzer for Python code;
it generates files of inferred type information,
located by default in .pytype/pyi.

See https://github.com/David-OConnor/pyflow for details.

See also 15e56afe introduced this for Rails.gitignore.

Docs on Sqlite temporary files
https://www.sqlite.org/tempfiles.html#rollback_journals

Thanks @nickittynack (Nick Reynolds)

The curly apostrophe in the comment is causing AWS EB CLI to fail. https://stackoverflow.com/a/55988700/594211

* Add ignore rules for Pipenv

Pipenv uses Pipfile.lock to maintain Python package information
(metadata, hash, etc.) installed as described in Pipfile. Thus,
Pipfile.lock may vary on different operating systems, platforms
when collaborating. This PR adds Pipfile.lock into the Python
default gitignore. See http://pipenv.org

* Update Python.gitignore

Not to ignore Pipfile.lock in default, but explain
when and why it should be ignored in case of
collaboration. (adjusted according to comment
in github/gitignore#2977 by @drothmaler )

* Apply suggestions from code review
Co-Authored-By: NJarryShaw <jarryshaw@icloud.com>

* Update Python.gitignore

As suggested by @shiftkey , elaborate on the problems that users might see with `Pipfile.lock`.

PEP-517 has resulted in some updates to the Python
build process. As a result, a new directory called
pip-wheel-metadata is created on fresh builds.
This PR adds this directory into the Python default
gitignore. See
https://github.com/pypa/pip/blob/e5f4bbb7ddff87f48f2b5815513e4211ccdde83a/src/pip/_internal/req/req_install.py#L568

See https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html

tl;dr Debian Policy requires wheels to be installed here and thus issuing
python3 -m venv .
on a Debian-like system creates this directory

Pyre is a new type-checker for Python developed by facebook in May 2018.
https://pyre-check.org/

It makes .pyre directory for storing result or cache for type checking.
This directory is environment dependent. So it should be ignored from Git.

See: https://github.com/theacodes/nox

My preference is for files to have a terminal newline, however that
doesn't seem to be how this repo is doing things.

Older versions of dmypy used 'dmypy.json' without the initial '.'.
This should be added to Python.gitignore for those using older versions
of MyPy.

MyPy includes a daemon server that creates a file named .dmypy.json to
manage socket connection data.

Both are neither python-specific nor django-specific:
- .static_storage
- .media

Terrarium backs up old virtual environments by moving them to this dir.

add MANIFEST which is GENERATED by distutils

Reasons for making this change:

if you use distutils.core to setup, the file MANIFEST is generated by distutils when run 'python setup.py sdist'

Some of these names relate to specific tools, others could be used by multiple tools. In particular, virtualenv, the most popular tool for creating Python environments, does not mandate any of these and venv/ or .venv are simply conventional. It is more readable to group all of these together.

[mkdocs](http://www.mkdocs.org/) is rising as an alternative to Sphinx for project's documentation. The default build command puts the generated documentation in a `site` directory at the root of the project which should be ignored.

Looks like Spyder 3.1 uses .spyproject folder to store workspace config