Talk:Python

Python 2 and 3

Python#Python_3 doesn't mention http://python-future.org/ . It has been recently added to the repos: python-future. I know nothing about python, so I just dropped a note here. -- Karol (talk) 10:54, 30 August 2015 (UTC)

I know python well, but I don't know what's "python-future" xD We can add info about it if another users say it's a good idea -- Kycok (talk) 13:19, 30 August 2015 (UTC)

__future__ allows you to use python3 syntax in python2 scripts. Looking at the file list of python-future this is a step up from that. -- Alad (talk) 19:27, 30 August 2015 (UTC)

To me it seems like a regular Python package (with rather self-assured name), providing tools similar to the older and limited 2to3 tool. It's not a new implementation or something like that, the future of Python is to switch to the 3 branch completely. I have no idea why they still (unofficially) backport everything to the 2 branch, thus delaying the inevitable. -- Lahwaacz (talk) 19:59, 30 August 2015 (UTC)

"allows you to use python3 syntax in python2 scripts"

So, we can add it in "Dealing with version problem in build scripts" and/or "Tips and tricks" section(s) temporarily, while python2 is widely used -- Kycok (talk) 20:15, 30 August 2015 (UTC)

That section is targeted at packagers, dealing mainly with the python -> python3 symlink. As far as I understand, the code has to be written explicitly for python-future (or converted automatically and checked) in order to use their features, it can't be used by packagers just for building the packages. -- Lahwaacz (talk) 20:23, 30 August 2015 (UTC)

Improve the recommendations on the "Package management" section

I'd like to sugest some edits in this section, speciall concerning user installed python packages (not system wide installed) and available tools to do it.

Much as happened lately, and some new, solid and idiotproof tools are available today, that were not before. One good example is pipx, https://pipxproject.github.io/pipx/ . I noticed there's a surge in github reccomending this.

I cannot recommend enough, to read their README/FAQ page, as it helps understand not only their tool compared to others, but the recent panorama of similar python tools

This is in my opinion worth the effort, as python is a very popular language, and as much as a lot of stuff is available officially and/or the AUR, there will always be some interesting app, that isnt there.

This is especially important for end users (not programmers/developers) who just want to try out, in a clean and safe way, a (cli) python app, not available in the AUR. They are not focused on installing libraries or dependencies for programming or scripting their own app. It's important to stress and instruct the less informed users, as to not bork their system doing this.

As of now we have this super important opening tip:

   Official repositories and AUR — A large number of popular packages are available in the Arch repositories. This is the preferred way to install system-wide packages.

Then comes pip:

   pip — The official package installer for Python. You can use pip to install packages from the Python Package Index and other indexes.

This was for some time the only way to do it. Still many beginners are not aware of the difference between "pip install XXX" and "pip install --user XXX". And because the Internet is full of bad advice, many end up doing "sudo pip install"

This cannot stop being stressed: - warning about the "sudo pip install XXX" - mention the --user flag

I would suggest to move up here, this note that was at the end

   When installing packages from sources other than the official repositories and AUR, it is recommended to use a virtual environment (or Conda environment management) to prevent conflicts with system packages in /usr. Alternatively, pip install --user can be used to install packages into the user scheme instead of /usr.

Additionally, since it's so dead simple, with tools already available in the system, suggest right here that:

"pip install XXX" can be done in a virtual environment for quick testing, with the super simple:

   $ python -m venv envname
   $ source envname/bin/activate
   (envname) $

and then run the pip install inside it

   $ pip install XXX

with a link to, https://wiki.archlinux.org/index.php/Python/Virtual_environment

Now for the new kid on the block. Add an entry with a recommendation to pipx, https://pipxproject.github.io/pipx/. Maybe copy and reuse some of their documentation, especially:

- How is it Different from pip? - Comparison to Other Tools

Then comes this old entry for Conda, which isnt't even in the official repos, only AUR. So in my opinion should be at the end or removed from here

This should be moved to the end:

   Historically, easy_install (part of python-setuptools) was used to 

And almost hidden at the end:

  Tip: pipenv provides a single CLI for Pipfile, pip and virtualenv. It is available as python-pipenv.

pipenv should should be listed right after pipx.

-- M040601 (talk) 02:48, 1 October 2020 (UTC)

We won't make any recommendations based just on "surges" in Github recommendations. -- Lahwaacz (talk) 17:08, 1 October 2020 (UTC)

The easy_install mention is a holdover from an older version of the page that suggested using it. I added that note to make it clear that easy_install should no longer be used. I like the suggestion on making it more obvious why sudo pip is a bad idea. I also don't see harm in adding pipx to the list. Dharmab (talk) 23:52, 1 October 2020 (UTC)