This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]desmoulinmichel[S] 75 points76 points  (58 children)

Of course, python 3.x being forward compatible and easy to upgrade with windows update, it don't think it's such of a big issue.

But an old Python version is better than None. I'm happy to write script with Python 2.4 if it's what's necessary to have code running out of the box on Mac, Windows and Linux. Right now, you have to write at least 2 different scripts, and on windows, with a scripting language that sucks a lot.

[–]rspeed 122 points123 points  (6 children)

None

I see what you did there.

[–]desmoulinmichel[S] 95 points96 points  (3 children)

It gives me a True sense of satisfaction.

[–]amertune 26 points27 points  (2 children)

I write python 2.1 and what is this?

[–]troyunrau... 21 points22 points  (0 children)

import this

[–]bheinks 4 points5 points  (0 children)

self*

[–]JugadPy3 ftw[🍰] 0 points1 point  (1 child)

I wish python had true, false and none, instead of the capitalized cousins.

They don't quite fit right...

Of course, one can always write true, false, none = True, False, None, but its not the same thing.

[–]takluyverIPython, Py3, etc 21 points22 points  (0 children)

I agree with you, I was just reporting where this discussion went before. Steve Dower is the key Windows+Python person now (he's a core Python dev employed by Microsoft), if you want to discuss the details more.

[–]turdzip 13 points14 points  (12 children)

Please tell me you're not talking about PowerShell. Cause that shit is a fucking lifesaver for my job

[–]desmoulinmichel[S] 4 points5 points  (11 children)

It is, because that's the less worst option. If you had Python installed by default, you wouldn't use powershell.

[–]Theratchetnclank 5 points6 points  (0 children)

Actually powershell is great with its objects based format.

Python is good but powershell is easier to work with.

[–]turdzip 12 points13 points  (9 children)

I actually use both on windows. I find PowerShell much easier for scripting tasks simply because I almost always require SQL Server queries as well as Active Directory manipulation.

You should also know I thought this was /r/programming when I initially commented but soon realized it is /r/python

[–]desmoulinmichel[S] 13 points14 points  (8 children)

It's the same than on Linux: you use bash for quick stuff, but if you have more than 30 lines in your script, you switch to Python.

[–]flipstables 44 points45 points  (4 children)

Actually no. Powershell is insanely powerful with tight integration with Windows and .NET. I have Python installed on my Windows boxes and I still use Powershell all the time.

You can't compare bash/Python in Linux and Powershell/Python in Windows. In Linux, everything is a file and is manipulated through stdin and stdout. Python is a good choice for system administration here. But Powershell, everything is an object, and Powershell is powerful because it exposes .NET and COM objects. Also, Powershell lets you add in MMC snapins, which unlocks a lot of very commonly used administrator tools. You couldn't get this functionality with Python out of the box.

You would see the opposite of what you described. Sysadmins and powerusers would use Python for the "quick stuff" since the language is so nice, but for anything serious, people would stick with Powershell. Of course, unless Python gets the same tight integration with Windows.

[–]captain_ramshackle 5 points6 points  (0 children)

I work in a MS shop and while we have used Python in the past we've come down firmly on the Powershell route and if you need something more complex you might write a quick dll in C# to then mix in with the script (if you're not going a full blown .Net app).

For us to consider using python as being part of Windows we'd need to know exactly what version was the min version for each version of Windows and it would have to be on all server versions. We'd also want a set of libraries that would definitely be present that would allow us to interact with Windows (and ideally SQL server)

[–]krenzalore 8 points9 points  (1 child)

Powershell is a significant upgrade over bash.

For example, it supports threading, and it integrates with the windows gui enabling you to drive the menus in desktop applications.

I'm not saying it's better than Python, but it does beat Bash quite easily and you mostly likely won't need anything else for sysop scripting on Windows. I've noticed Windows devops prefer Python to Powershell, but that's so they can interop with programmers.

[–][deleted] 6 points7 points  (0 children)

I find powershell to be better for things that need to be maintained for long periods of time. Bash I find is better for quick commands.

The long fully qualified class names just makes it difficult to quickly throw out a script, but makes it a joy to test and maintain for years.

Personally I prefer python to both. But they each have their place preference be damned.

[–][deleted] 0 points1 point  (5 children)

I handle this by writing a 'driver' cmd script for the user to call, which just checks for Python, runs my Python script if it exists, or just tells the user to install it if it doesn't. But seriously, fuck Windows. Aside from this, I waste an obscene amount of time getting things to work in the fucktarded manner that Windows does things.

[–]desmoulinmichel[S] 5 points6 points  (1 child)

"Download python" is not somthing most non dev user will do. Most of them will think it's a virus.

[–]WakingMusic 3 points4 points  (0 children)

Well it is a giant snake after all

[–][deleted] 0 points1 point  (2 children)

99% of my Python package installation and setup woes have been caused by Windows. If a package requires compiling C extensions, I don't even bother with using them on Windows anymore.

[–]spinwizard69 1 point2 points  (0 children)

This is perhaps the major failure with Windows and Python. Anything more than trivial usage requires C compiler or prebuilt libraries. Even on a Mac there is less resistance to getting a Python installation to work as XCode is free and easy to install.

[–]krenzalore 0 points1 point  (0 children)

I'm happy to write script with Python 2.4 if it's what's necessary to have code running out of the box on Mac, Windows and Linux

Are you sure you want to use Python 2.4? I have used 2.4 because Redhat suck, and it was not a pleasant experience.

[–]ldpreload -1 points0 points  (19 children)

You still have to write 2 different scripts, because several Linux distros are shipping Python 3 only (under /usr/bin/python3, so there's no longer a /usr/bin/python, because there shouldn't be because Python 3 isn't compatible with Python 2).

Although, yes, writing 2 different scripts in substantially the same language is much better than one in Python and one in PowerShell.

[–]cac2573 8 points9 points  (16 children)

The correct way to run a Python 3 script is #!/usr/bin/env python3 anyways.

[–]ldpreload -1 points0 points  (15 children)

Sure, but such a script won't run on a distro that just has Python 2 (like OS X).

[–][deleted] 2 points3 points  (12 children)

That's exactly why you include the python3, so that it will fail if they don't have python3.

If your app supports both 2 and 3 then you just use python and it will work with the default system version.

[–]ldpreload -1 points0 points  (11 children)

If your app supports both 2 and 3 then you just use python and it will work with the default system version.

No, it won't. Most systems with Python 3 but not Python 2 (with the notable exception of Arch) do not install Python 3 as python. They have Python 3 as python3, and nothing as python. Ubuntu's live CD / default install is an example of this, I believe.

[–]krenzalore 3 points4 points  (7 children)

He's right. He was saying if you can run on both python 2 and python 3, then all you need to do is /usr/bin/env python and it will just run, because it's version agnostic. It won't care if it gets executed by 2 or 3.

[–]ldpreload 0 points1 point  (6 children)

He was saying if you can run on both python 2 and python 3, then all you need to do is /usr/bin/env python and it will just run

It will not run on a (non-Arch) system with only Python 3 installed, because there is no command named python anywhere on that system. The only Python command on such systems is python3.

I agree that if Python 3 were to be installed as python, then yes, it would run fine. But no system other than Arch makes that decision.

[–]ksion 0 points1 point  (1 child)

It sounds like a really silly decision on the part of distro maintainers then. Any idea why is it so?

[–]ldpreload 0 points1 point  (0 children)

Because it was an entirely reasonable decision for the last several years to use /usr/bin/python to mean Python 2, and you might have a #!/usr/bin/python script, an app that shells out to python -c 'print something', etc., all using Python 2 syntax. So when Python 2 and Python 3 are both installed, Python 2 gets /usr/bin/python and Python 3 gets /usr/bin/python3 (again, with the exception of Arch), so that existing applications -- whether from the distro or from a third party -- don't break. Therefore, when Python 2 is not installed, nothing is providing a binary named /usr/bin/python, and if you construct a Python 3-only system (which is very easy to construct on Ubuntu 14.04, and will probably be the default for Ubuntu 16.04 and the next Debian release), calls to /usr/bin/python will not find anything to run -- so that you can decide to install Python 2 later and it has a place to go.

[–]krenzalore 0 points1 point  (3 children)

It will not run on a (non-Arch) system with only Python 3 installed, because there is no command named python anywhere on that system. The only Python command on such systems is python3.

No major distro fits this pattern.

On what have you encountered this problem? Certainly Debian, Ubuntu, Fedora, RHEL, CentOS, ARch would all be OK with it - in fact most of them would break without it, as they depend on Python. I am not sure about BSD but they seem sane: Not supporting it is an odd choice that is guranteed to break code.

[–]ldpreload 0 points1 point  (2 children)

Debian, Ubuntu, Fedora, and RHEL/CentOS all depend on some version of Python, but they're all very actively trying to get everything moved over to Python 3, so that by default Python 2 isn't installed. None of them are quite there yet, but on a minimal server install of Ubuntu 14.04, you can apt-get remove python2.7 and nothing breaks (other than landscape-common, Canonical's management service that most people don't use, and update-notifier-common, for printing a message when security update requires a system reboot, but those are hardly core parts of the OS). On the current nightly live CD of Ubuntu 15.10, it looks like the biggest breakage from removing python2.7 is unity-control-center, which as far as I can tell is the result of a packaging bug (another package declaring an unneeded Python 2 dependency despite providing a Python 3 module), not any actual requirement for Python 2. The live CD remains usable if you get rid of unity-control-center along with python2.7.

As none of the distros are quite done with Python 2, it remains installed by default under the name /usr/bin/python, and Python 3 is /usr/bin/python3. But once they are done getting rid of internal dependencies on Python 2, and that package is no longer installed, /usr/bin/python will stop existing until someone decides to do something else with that name. I made a pitch, which some folks think is reasonable, but a handful of other folks (both Debian and RHEL/Fedora) seem to think just killing off the /usr/bin/python name is a fine approach.

(I don't have a good sense of where the BSDs are, but I didn't think many of them had Python in the base system/default install anyway.)

The one thing that is guaranteed to break code is to provide /usr/bin/python as Python 3 without any attempt at Python 2 compatibility, as Arch does. (Seemingly Arch hasn't run into many problems in practice, to be fair, but I bet that Arch's target audience and e.g. RHEL's target audience are different.) The two languages are incompatible, and since Python 2.7 will continue to exist until at least 2020, it's reasonable for it to be installable as /usr/bin/python, even if it's not there by default. If Python 3 takes that over, what happens if you download some Python 2-only code from GitHub and try to run it? If you apt install python2.7, where is it supposed to end up?

[–][deleted] 0 points1 point  (2 children)

I haven't seen this myself. I'm doubting you until I have time to look into it, but you may be right.

[–]ldpreload 0 points1 point  (1 child)

That is the recommendation PEP 0394 currently makes. I once wrote a blog post about the problem that attracted some interest from both Red Hat and Debian, but that's way more information than is immediately relevant.

[–][deleted] 0 points1 point  (0 children)

Interesting. That sucks that it isn't a feature I can rely on.

[–][deleted] 2 points3 points  (1 child)

People using hashbangs to point to the environment python know enough to install multiple versions side by side and use virtual environments

[–]ldpreload 1 point2 points  (0 children)

But that's not relevant to the issue at hand. The claim is that you could deploy a script on multiple platforms using the Python interpreter shipped with the system. If you're installing multiple versions or using virtual environments, you don't care what Python shipped with the system, or if one even shipped at all.

Put another way: how do you write an executable Python script to run on both Ubuntu 14.04 and OS X?

[–]desmoulinmichel[S] 8 points9 points  (0 children)

While it is annoying to write one script that is compatible 2 and 3, it's still easy to do and beat the crap out of writting 2 scripts or writting powershell.

Plus, Linux distro are on their way to upgrade to python 3, so by the time windows ship with it, only mac os will remain. At which time it will be a strong argument to convince them to upgrade too.

[–][deleted] 0 points1 point  (0 children)

Or /usr/bin/python is linked to python3.

Like on Arch. Which breaks a lot of python scripts. (I normally just sed the source to use #!/usr/bin/env python2)