5 ms·

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of both. This is a terrible state of affairs.

craigds 9y ago
Nonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings
- ridiculous_fish 9y ago
  Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." tox apparently depends on virtualenv; this is reasonable if your software is primarily Python, but absurd if your package merely uses Python for one-off scripts. macOS doesn't even install pip by default. I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.
  - takeda 9y ago
    > Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." You can writes compatible Python code without using any extensions, I did that myself, but those tools just make it easier. > I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities. Since you mentioned FreeBSD I need to add that while ago they had an effort to remove any scripting language from the base system. So FreeBSD doesn't come with Perl, Python, Ruby etc preinstalled. Actually, I think that was a really good decision. No need to worry that system depends on some old Python module which if you upgrade, you can break it. Instead, you need python3.6? You install that version, you realize that something else needs python2.7? You install python2.7 side by side. In fact you can install all available versions without conflicts or worrying that something will break.
  - pseudalopex 9y ago
    Using virtualenv for development doesn't mean your users have to install it. The Python website has some pages on supporting both major versions.[1][2] [1] https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef [2] https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html
joshuamorton 9y ago
#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
- Ndymium 9y ago
  To be fair that was written _after_ Arch made their choice and if it's not easy to make that choice, it's sure not easy to reverse it either.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- reificator 9y ago
  Sure, if you can make up the rules after someone breaks them, then Arch is wrong... From the linked PEP (emphasis mine) > end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP)

craigds 9y ago

Nonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings

ridiculous_fish 9y ago
Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." tox apparently depends on virtualenv; this is reasonable if your software is primarily Python, but absurd if your package merely uses Python for one-off scripts. macOS doesn't even install pip by default. I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.
- takeda 9y ago
  > Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." You can writes compatible Python code without using any extensions, I did that myself, but those tools just make it easier. > I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities. Since you mentioned FreeBSD I need to add that while ago they had an effort to remove any scripting language from the base system. So FreeBSD doesn't come with Perl, Python, Ruby etc preinstalled. Actually, I think that was a really good decision. No need to worry that system depends on some old Python module which if you upgrade, you can break it. Instead, you need python3.6? You install that version, you realize that something else needs python2.7? You install python2.7 side by side. In fact you can install all available versions without conflicts or worrying that something will break.
- pseudalopex 9y ago
  Using virtualenv for development doesn't mean your users have to install it. The Python website has some pages on supporting both major versions.[1][2] [1] https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef [2] https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html

joshuamorton 9y ago

#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/

Ndymium 9y ago
To be fair that was written _after_ Arch made their choice and if it's not easy to make that choice, it's sure not easy to reverse it either.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
reificator 9y ago
Sure, if you can make up the rules after someone breaks them, then Arch is wrong... From the linked PEP (emphasis mine) > end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP)